hey all and thanks again for the response. ive actually updated to buster (incase you wonder why i havent so far, i just did not have a reason, its an embedded system and it was working great until i had the idea of using pd~ in order to free up the cpu) so im on 0.49 now but still no luck. a simple test patch sending and osc~ out to the dac~ does not produce sound, the mother patch has its dsp on (with delay and all) and i can print msgs via [stdout] so the sub patch is def loading. pd~ has the following  arguments: [pd~ -ninsig 1 -noutsig 1 -fifo 20 -sr 48000]. it does work on my mac tho. while im at it, incase i ever get it to work, the docs states that the fifo latency is roundtrip in blocks. does this refer to pd block size of 64 time the number of fifo that i specify in the args?

 

 thanks again

 

 

 

 

 

On Mon, Sep 16, 2019 at 4:18 PM Max <abonnements@revolwear.com> wrote:

On 16.09.19 12:54, Christof Ressi wrote:
>> if you want to use pd~ to for example render a GEM patch you need to
>> switch on dsp in the subprocess at least for a moment.
>
> I don't think you need to do this (anymore). Control objects work fine without DSP being turned on in the subprocess, like the documentation says.

OP is using 0.47 on the RPi, so  ¯\_(ツ)_/¯



_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list