میٹنگز اور ٹرانسکرپشن

Control Center کسی کال کو ریکارڈ کر سکتا ہے اور آپ کو ایک صاف تحریر واپس دے سکتا ہے — ایک خلاصہ، ایکشن آئٹمز اور فیصلے — جس میں اسپیچ ریکگنیشن اور اسپیکر کی علیحدگی آپ کے اپنے ہارڈ ویئر پر چلتی ہے۔ Granola کا تصور کریں، مگر خود میزبان اور اُسی ورک اسپیس سے منسلک جس میں آپ کے ایجنٹ رہتے ہیں۔

ریکارڈنگ کے لیے وائس ماڈل اور سرور ری اسٹارٹ درکار ہے

ریکارڈنگ اور ڈکٹیشن اُس وقت شروع ہوتے ہیں جب اسپیچ (ASR) ماڈل ڈسک پر موجود ہو اور سرور ری اسٹارٹ ہو چکا ہو۔ ایک عام بوٹ پس منظر میں منتخب ماڈل (ڈیفالٹ کے طور پر Parakeet TDT 0.6B v3) زبردستی انسٹال کرتا ہے، لیکن سرور وائس ماڈل کے راستے بوٹ کے آغاز کے قریب بالکل ایک بار حل کرتا ہے — اُس ڈاؤن لوڈ کے مکمل ہونے سے کئی منٹ پہلے۔ ماڈل کے انسٹال شدہ ہونے کی اطلاع ملنے کے بعد cc_server کو ری اسٹارٹ کریں۔ کوئی مختلف بلڈ چننے کے لیے ترتیبات → سرور → آواز اور میٹنگ ماڈلز استعمال کریں — اُس کے لیے بھی ری اسٹارٹ درکار ہے۔

میٹنگ کیا ہوتی ہے

میٹنگ ایک ریکارڈ شدہ، ٹرانسکرائب شدہ نشست ہوتی ہے۔ یہ نہیں وہی چیز ہے جو کیلنڈر ایونٹ ہے: ایونٹ ایک شیڈول شدہ وعدہ ہوتا ہے جو Google سے سنک ہوتا ہے، جبکہ میٹنگ وہ چیز ہے جو آپ نے واقعی ریکارڈ کی۔ دونوں کو آپس میں لنک کیا جا سکتا ہے، کیونکہ آپ کسی ایونٹ سے ریکارڈنگ شروع کر سکتے ہیں، مگر وہ الگ الگ ریکارڈ رہتے ہیں۔

ہر میٹنگ ورک اسپیس تک محدود ہوتی ہے، بالکل Control Center کی باقی ہر چیز کی طرح۔ ایک ورک اسپیس میں ریکارڈ ہونے والی میٹنگز کبھی دوسری میں ظاہر نہیں ہوتیں۔

کام کہاں ہوتا ہے

”آن ڈیوائس“ درست فطری رجحان ہے مگر غلط لفظ۔ کلائنٹ آڈیو کیپچر کرتا ہے اور 16 kHz PCM16 فریمز cc_server چلانے والی مشین کو اسٹریم کرتا ہے۔ وہ میزبان باقی سب کچھ کرتا ہے: یہ فی چینل WAVs <dataDir>/meetings/<meetingId>/ کے تحت لکھتا ہے، ایک ورکر آئسولیٹ میں ٹرانسکرائب کرتا ہے، ایکو فلٹر کرتا ہے اور بعد ازاں ڈائرائز کرتا ہے۔ کسی اسٹینڈ الون ڈیسک ٹاپ پر وہ میزبان وہی مشین ہوتا ہے۔ ریموٹ سرور کی طرف اشارہ کرنے پر ایسا نہیں ہوتا — اس لیے ”میرے لیپ ٹاپ سے کچھ باہر نہیں جاتا“ صرف اُس وقت درست ہے جب سرور آپ کا لیپ ٹاپ ہو۔

ایک اور استثنا بھی ہے، اور وہی اہم ہے۔

خلاصہ ہوسٹ سے باہر جاتا ہے

ٹرانسکرپٹ اور آپ کے نوٹس اُس ماڈل فراہم کنندہ کو بھیجے جاتے ہیں جس کے خلاف خلاصہ بنانے والا ایجنٹ کنفیگر ہو۔ کسی بھی کلاؤڈ فراہم کنندہ کے لیے اِس کا مطلب ہے کہ پوری ٹرانسکرپٹ اُس فراہم کنندہ کے API پر جاتی ہے۔ اگر کسی ٹرانسکرپٹ کو ہوسٹ سے باہر نہیں جانا چاہیے تو خلاصہ بنانے والے ایجنٹ کو کسی مقامی اینڈ پوائنٹ (Ollama، LM Studio یا کوئی دوسرا مقامی سرور) کی طرف اشارہ کریں۔

خلاصے سے پہلے کا سب کچھ — کیپچر، ٹرانسکرپشن، ایکو کی منسوخی، ڈائرائزیشن، وائس پرنٹ کی مماثلت — سرور پر بغیر کسی نیٹ ورک کال کے چلتا ہے۔

کون سے ماڈلز شامل ہیں

ایمبیڈنگ، ڈائرائزیشن اور اسپیچ (ASR) ماڈلز پہلے بوٹ پر زبردستی انسٹال ہوتے ہیں (ڈیمو پر چھوڑ دیے جاتے ہیں)، اس لیے اسپیکر کی علیحدگی اور ریکارڈنگ بغیر ترتیبات میں جائے موجود ہوتے ہیں۔ ASR پھر بھی قابلِ انتخاب ہے — یہ کئی سو میگا بائٹس کا ہے، اور پکر میں چار بلڈز شامل ہیں۔ اُس پہلے ڈاؤن لوڈ کے بعد اسپیچ کو پھر بھی ایک ری اسٹارٹ درکار ہوتا ہے، کیونکہ ٹرانسکرائبر اپنا ماڈل حاصل کرنے کا عمل مکمل ہونے سے پہلے حل کر لیتا ہے۔

پکر کی چار اندراجات، جو حجم، زبان کی کوریج اور درستگی میں مختلف ہیں:

• Parakeet TDT 0.6B v3 — کثیراللسانی، تجویز کردہ ڈیفالٹ (~600 MB)
• Parakeet TDT 0.6B v2 — انگریزی (~480 MB)
• Whisper large-v3-turbo — کثیراللسانی (~626 MB)
• Whisper base.en — صرف انگریزی، چھوٹا تاریخی ڈیفالٹ (~198 MB)

ماڈلز واحد چیزیں ہیں جو سرور رن ٹائم پر حاصل کرتا ہے؛ ہر نیٹو لائبریری بنڈل میں شامل ہوتی ہے۔

کیپچر کیسے کام کرتا ہے

میٹنگ بیک وقت دو آڈیو چینلز ریکارڈ کرتی ہے:

• آپ (“me”): آپ کا مائیکروفون۔
• وہ (“them”): میٹنگ کی آڈیو آؤٹ پٹ، جو ڈرائیور سے پاک loopback کے ذریعے کیپچر ہوتی ہے — macOS پر Core Audio process/device taps، Windows پر WASAPI loopback، Linux پر PipeWire / PulseAudio monitor۔

چونکہ دونوں چینلز الگ الگ کیپچر ہوتے ہیں، ٹرانسکرپٹ شروع ہی سے اسپیکر سے منسوب ہوتی ہے: آپ کے الفاظ me کا ٹیگ رکھتے ہیں، اور کال میں موجود ہر شخص them کا۔

آپ کی اپنی آواز سسٹم آؤٹ پٹ سے رس کر واپس مائیکروفون میں آ جاتی ہے اور ورنہ دو بار ٹرانسکرائب ہوتی۔ دو فلٹر اُسے روکتے ہیں۔ سگنل کی سطح پر AEC3 ہر ریموٹ موڈ ریکارڈنگ پر چلتا ہے اور لازمی ہے — اگر نیٹو AEC لائبریری لوڈ نہ ہو سکے تو ریکارڈنگ خاموشی سے ایکو سے آلودہ مائیکروفون اسٹریم کرنے کے بجائے شروع ہونے سے انکار کر دیتی ہے۔ (اِن پرسن موڈ میں منسوخی کے لیے دور کا کوئی حوالہ نہیں ہوتا، اس لیے وہاں AEC بغیر تبدیلی گزر جاتا ہے۔) اُس کے علاوہ، ہوسٹ کی طرف سے متن کی سطح کا ایکو فلٹر ہر پلیٹ فارم پر چلتا ہے۔

OS کی سطح پر مائیکروفون کی تمام پروسیسنگ جان بوجھ کر غیر فعال رکھی جاتی ہے۔ macOS پر پلیٹ فارم کی اپنی ایکو منسوخی یا آٹو گین فعال کرنے سے مائیکروفون Voice Processing I/O پر چلا جاتا ہے، جس نے اِس بلڈ میں مائیکروفون اور سسٹم آڈیو ٹیپ دونوں کو ختم کر دیا۔

ٹرانسکرپشن اور ڈائرائزیشن

جب آپ ریکارڈ کرتے ہیں تو آڈیو رولنگ ونڈوز میں، UI تھریڈ سے ہٹ کر، ڈی کوڈ ہوتی ہے — ہر ونڈو کسی مختصر آخری خاموشی پر، یا زیادہ سے زیادہ ونڈو لمبائی پر کاٹی جاتی ہے۔ ہر ونڈو ملی سیکنڈ آفسیٹس کے ساتھ اسپیکر کے ٹیگ والا ٹرانسکرپٹ سیگمنٹ بن جاتی ہے۔

جو ونڈوز کبھی RMS کی حد سے اوپر نہ اٹھیں وہ بالکل بھی ڈی کوڈ کیے بغیر چھوڑ دی جاتی ہیں، کیونکہ اسپیچ ماڈل خاموشی کو من گھڑت غیر اسپیچ ٹوکنز کے طور پر پیش کرتا ہے اور ڈی کوڈ ضائع شدہ CPU ہوتا ہے۔ عملی نتیجہ: مسلسل بہت مدھم بولنے والا اسپیکر کوئی ٹرانسکرپٹ نہیں دیتا۔ اگر کوئی خالی واپس آئے تو ماڈل کو قصوروار ٹھہرانے سے پہلے اُس کی ان پٹ لیول چیک کریں۔

آپ کے رکنے کے بعد، ڈائرائزیشن ریکارڈنگ پر آف لائن چلتی ہے اور ریموٹ چینل کو الگ الگ اسپیکرز (Person 1, Person 2, …) میں تقسیم کرتی ہے جنہیں آپ دوبارہ نام دے سکتے ہیں۔ اسپیکرز کی تعداد کسی کلوسٹرنگ حد سے اخذ کی جاتی ہے، نہ کہ آپ کی مقرر کردہ گنتی سے — اس لیے یہ ایک حد کا نتیجہ ہوتی ہے اور کوئی مدھم یا اوورلیپ کرنے والا اسپیکر پڑوسی میں ضم ہو سکتا ہے۔ ٹرانسکرپٹ [mm:ss] SPEAKER: text لائنوں کی صورت میں پیش کی جاتی ہے۔

وائس پروفائلز

کسی اسپیکر کا نام بدلنا صرف ایک ٹرانسکرپٹ کو لیبل لگانے سے زیادہ کرتا ہے۔ Control Center اسپیکر کا وائس پرنٹ وائس پروفائل کے طور پر محفوظ کر سکتا ہے، تاکہ یہ آئندہ میٹنگز میں اُنہیں خودکار طور پر پہچان لے۔ جب آپ کسی ڈائرائز شدہ اسپیکر کو نام دیتے ہیں تو آپ سے پوچھا جاتا ہے کہ وائس پرنٹ محفوظ کرنا ہے یا نہیں؛ اگر آپ کریں تو یہ اُس نام کے لیے ایک جاری سینٹروائیڈ میں ملایا جاتا ہے اور نئے اسپیکرز سے کوسائن مماثلت کے ذریعے موازنہ ہوتا ہے، تاکہ وہی شخص اگلی بار آپ کے دوبارہ لیبل کیے بغیر اپنے نام کے ساتھ ظاہر ہو۔

وائس پروفائلز ورک اسپیس تک محدود ہوتی ہیں اور کبھی حد پار نہیں کرتیں۔ اُنہیں ترتیبات → ورک اسپیس → میٹنگز پر منظم کریں۔ کسی ایسے اسپیکر کا نام بدلنا جسے پہلے محفوظ کیا گیا تھا، پرانے نام کو اَن اِنرول کرتا ہے اور نیا نام اِنرول کرنے کی پیشکش کرتا ہے؛ کوئی پروفائل حذف کرنا محفوظ وائس پرنٹ ہٹا دیتا ہے مگر ماضی کی میٹنگز پر پہلے سے لاگو نام بغیر تبدیلی چھوڑ دیتا ہے۔

خلاصے کی پائپ لائن

جب ریکارڈنگ رکتی ہے تو سرور ایک MeetingRecordingStopped ڈومین ایونٹ شائع کرتا ہے۔ بلٹ اِن meeting_summary پائپ لائن ٹیمپلیٹ اُسی ایونٹ سے ٹرگر ہوتا ہے۔ ریکارڈر اُس کا انتظار نہیں کرتا؛ میٹنگ محض اپنی اسٹیٹس لائف سائیکل سے گزرتی ہے:

recording → processing → done

خلاصے والا ایجنٹ عنوان، آپ کے موٹے موٹے لائیو نوٹس اور ٹرانسکرپٹ وصول کرتا ہے اور ساختی JSON واپس کرتا ہے۔ یہ کون سے سیکشن لکھتا ہے، وہ ورک اسپیس کے فعال میٹنگ نوٹ ٹیمپلیٹ سے طے ہوتا ہے (ترتیبات → ورک اسپیس → میٹنگز)؛ فعال ٹیمپلیٹ نئے اور دوبارہ چلائے گئے خلاصوں پر لاگو ہوتا ہے۔ پھر پائپ لائن کے محفوظ کرنے والے قدم اُس JSON کو الگ الگ قطاروں میں لکھتے ہیں:

• enhancedNotes اور summary → میٹنگ کے نوٹس
• ہر ایکشن آئٹم → ایک MeetingActionItem قطار (مواد، ذمہ دار، اختیاری ٹکٹ لنک)
• ہر فیصلہ → ایک MeetingDecision قطار

ایکشن آئٹمز اور فیصلے کبھی آزاد markdown سے پارس نہیں کیے جاتے، صرف ایجنٹ کے ساختی ایریز سے۔ اگر کوئی رن ساختی آؤٹ پٹ پیدا نہ کرے تو محفوظ کرنے والے قدم چھوڑ دیے جاتے ہیں اور خام ٹرانسکرپٹ بطور متبادل رکھی جاتی ہے، تاکہ ریکارڈ کبھی ضائع نہ ہو۔ پائپ لائن میں کوئی چیز میٹنگ کو done نہیں کرتی — یہ کام ایک واحد ری کنسائلر رن کے ٹرمینل ایونٹ سے کرتا ہے، اس لیے کسی ہم رتبہ قدم کی ناکامی ایسی آدھی لکھی میٹنگ کو پھنس نہیں سکتی جو پہلے ہی مکمل دکھائی دے۔

ایجنٹس آپ کی میٹنگز نہیں پڑھ سکتے

میٹنگ یا کیلنڈر کے لیے کوئی MCP ٹولز نہیں ہیں۔ MCP کے ذریعے جڑا ایجنٹ میٹنگز کی فہرست نہیں بنا سکتا، ٹرانسکرپٹ نہیں پڑھ سکتا، اور نہ ایکشن آئٹمز اور فیصلے دیکھ سکتا ہے — یہ ڈیٹا صرف RPC کے ذریعے انسانی کلائنٹس تک پہنچتا ہے۔ فیصلے بالواسطہ طور پر ایجنٹس تک پہنچتے ہیں، decisions ڈومین میں میموری حقائق کے طور پر۔

میٹنگز کہاں ظاہر ہوتی ہیں

سطح	یہ کیا دکھاتا ہے
/meetings	میٹنگز کی فہرست، ایکشن آئٹمز اور فیصلوں کی گنتی کے ساتھ
/meetings/record	لائیو ریکارڈنگ HUD: ایک طرف آپ کے نوٹس، دوسری طرف اسٹریم ہوتی ٹرانسکرپٹ
/meetings/:meetingId	میٹنگ کی تفصیل: نوٹس، ٹرانسکرپٹ، ایکشن آئٹمز اور فیصلے ٹیبز
ترتیبات → ورک اسپیس → میٹنگز	اِس ورک اسپیس کے نوٹ ٹیمپلیٹس اور محفوظ شدہ وائس پروفائلز

پلیٹ فارم کی معاونت

تینوں ڈیسک ٹاپ پلیٹ فارمز پر کیپچر ڈرائیور سے پاک ہے (macOS پر Core Audio taps، Windows پر WASAPI، Linux پر PipeWire)۔

ویب کلائنٹ بھی ریکارڈ کرتا ہے، جسے اِس صفحے کا باقی ڈیسک ٹاپ تناظر چھپا سکتا ہے: براؤزر آپ کا مائیکروفون getUserMedia کے ذریعے اور میٹنگ کی آڈیو getDisplayMedia (اسکرین شیئر) کے ذریعے لیتا ہے، 16 kHz PCM16 پر ڈاؤن سیمپل کرتا ہے اور اُسی میزبان کو اسٹریم کرتا ہے۔ وہاں تین احتیاطی باتیں لاگو ہوتی ہیں:

• شیئر کی گئی سطح پر آڈیو ٹریک لازمی ہے۔ Safari، Firefox اور macOS کی فل اسکرین شیئرنگ کوئی آڈیو نہیں دیتیں اور ریکارڈنگ شروع ہونے سے انکار کر دیتی ہے۔
• نیٹو AEC3 نہیں ہوتا۔ مائیکروفون پر براؤزر کی اپنی ایکو منسوخی طلب کی جاتی ہے؛ ہوسٹ کی طرف کا متنی ایکو فلٹر پھر بھی چلتا ہے۔ HUD مائیکروفون کے PCM سے چلنے والا ان پٹ لیول میٹر دکھاتا ہے۔
• خلاصہ دوبارہ چلائیں اور پروسیسنگ منسوخ کرنا صرف ڈیسک ٹاپ پر ہے۔

کیلنڈر کا ریکارڈنگ شروع کریں اور لنک کریں عمل صرف ڈیسک ٹاپ پر ہے اور ویب پر یہ صاف بتا دیتا ہے، حالانکہ میٹنگز اسکرین کا اپنا ریکارڈ فلو وہاں کام کرتا ہے۔

میٹنگ حذف کرنا اُس کی آڈیو پیچھے چھوڑ دیتا ہے

کسی میٹنگ کو حذف کرنا صرف اُس کی ڈیٹا بیس قطاریں ہٹاتا ہے۔ محفوظ رکھی گئی فی چینل آڈیو ڈائریکٹری <dataDir>/meetings/<meetingId>/ کبھی صاف نہیں کی جاتی — اُس کے لیے کوئی برقراری پالیسی، حجم کی حد یا GC صفائی نہیں ہے۔ اُس ڈسک کو واپس لینا سرور میزبان پر ایک دستی کام ہے۔

مزید دیکھیں

• کیلنڈر اور شیڈولنگ: کسی کیلنڈر ایونٹ سے سیدھا میٹنگ ریکارڈ کریں
• پائپ لائنز اور آٹومیشن: meeting_summary کے پیچھے کا انجن
• ٹکٹس اور تفویض: میٹنگ کے ایکشن آئٹمز کو ٹکٹس سے لنک کریں
• ڈومین ایونٹس: MeetingRecordingStopped اور MeetingStartingSoon
• میٹنگ ریکارڈ اور خلاصہ کریں