so I solved it by starting pd processes from the shell and communicating
to/from the main patch using OSC.
Yes, that's how you would typically manage independent Pd instances.
Christof
On 07.05.2023 10:00, Orm Finnendahl wrote:
Hi IOhannes, Christof,
in my use case the subprocesses don't need to receive/send audio to
the main process and pd~ seems to introduce additional latency so I
solved it by starting pd processes from the shell and communicating
to/from the main patch using OSC.
In any case it's good to know about mediasettings, that seems quite
useful.
--
Orm
Am Samstag, den 06. Mai 2023 um 10:18:22 Uhr (+0200) schrieb IOhannes m
zmoelnig:
Am 5. Mai 2023 21:57:37 MESZ schrieb Christof Ressi <i...@christofressi.com>:
[pd~] is designed to pipe audio through the subprocess. The code does not (or rather should not)
allow the subprocess to use a real audio device. Ideally, we should disable the "audio
settings" and audio API entries in the "Media" menu for subprocesses, as they don't
have any meaning in this context.
And just for the record: of course Christof is right (like always), and with my previous
answer I did not want that "mediasettings" would make things to start working
magically.
Only if changing the audio backend is possible somehow, then "mediasettings"
allowed you to do so programmatically and with a well-defined interface.
mfg.sfg.jfd
IOhannes
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
