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 sound
On Mon, Sep 16, 2019 at 8:35 PM iftah gabbai <[email protected]> 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 <[email protected]> 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 ¯\_(ツ)_/¯ >> >> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
