[PD] pd~ and rpi

iftah gabbai ift.gab at gmail.com
Mon Sep 16 21:18:09 CEST 2019

ok, it works, apparently - or at least on my system and in contradiction to
the documentation the dsp in the sub process MUST be on.... otherwise no

On Mon, Sep 16, 2019 at 8:35 PM iftah gabbai <ift.gab at gmail.com> wrote:

> 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 at 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 at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20190916/2d5f41ae/attachment-0001.html>

More information about the Pd-list mailing list