[PD] pd~ and rpi

[iftah gabbai]

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/ada6fb8c/attachment.html>