hello list, its my first email ever so i really hope i do the guidelines justice, i just missed the part about the gmail issue so chaned my adress to @googlemail , apologies if u got this email twice :)
i tried searching the list and google and couldn’t find too much info so i try here: im attempting to use (pd~) in a patch in order to use multicore processing on my rpi 3b+. it works fine on my mac using pd 0.50 but does not seem to work on my rpi running strech lite headless and pd 0.47. the closest i got is to get it to print info out of stdout and this is happening only when i start the dsp in the sub process which kinda contradicts the documantaion. i tested also using atest patch which is just an osc~ connected to a dac~ in the sub process but still no luck. i wonder if anyone ever got this to work? is it related to 0.47 and should i go thru the trouble of compiling / installing a newer version since 0.47 is the latest version available for strech lite as far as i understated?
thank you very much
hey there, thanks! may i ask if you use 0.47? i usually get error msgs also without the -stderr , will using it give me more information?
On Sun 15. Sep 2019 at 19:04, Christof Ressi christof.ressi@gmx.at wrote:
Hi,
im attempting to use (pd~) in a patch in order to use multicore
processing on my rpi 3b+.
I do this all the time and never had a problem... do you get any errors? since you run headless you might start Pd with "-stderr" to see the error messages in the terminal.
should i go thru the trouble of compiling / installing a newer version
compiling Pd on the raspberry pi is actually quite easy.
Christof
*Gesendet:* Sonntag, 15. September 2019 um 18:57 Uhr *Von:* "iftah gabbai" ift.gab@gmail.com *An:* "pd-list@lists.iem.at" pd-list@lists.iem.at *Betreff:* [PD] pd~ and rpi hello list, its my first email ever so i really hope i do the guidelines justice, i just missed the part about the gmail issue so chaned my adress to @googlemail , apologies if u got this email twice :)
i tried searching the list and google and couldn’t find too much info so i try here: im attempting to use (pd~) in a patch in order to use multicore processing on my rpi 3b+. it works fine on my mac using pd 0.50 but does not seem to work on my rpi running strech lite headless and pd 0.47. the closest i got is to get it to print info out of stdout and this is happening only when i start the dsp in the sub process which kinda contradicts the documantaion. i tested also using atest patch which is just an osc~ connected to a dac~ in the sub process but still no luck. i wonder if anyone ever got this to work? is it related to 0.47 and should i go thru the trouble of compiling / installing a newer version since 0.47 is the latest version available for strech lite as far as i understated?
thank you very much _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
im sshing and viewing it via terminal, no error msgs whatsoever, with or without the -stderr, i tried to compile 0.49 a couple of days ago and got "Unable to fetch some archives", i could dig in to that but before i do that is there anyone that can confirm that it ever worked on 0.47? or maybe even better: does anyone have a test patch i could try? maybe im still missing something?
thanks again!
On Sun 15. Sep 2019 at 19:39, Christof Ressi christof.ressi@gmx.at wrote:
I think I use Pd 0.49 (build from source). Do you do X11 forwarding? Otherwise you could connect keyboard, mouse and display and see what's going on. *Gesendet:* Sonntag, 15. September 2019 um 19:09 Uhr *Von:* "iftah gabbai" ift.gab@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at *Cc:* Pd-List pd-list@lists.iem.at *Betreff:* Re: [PD] pd~ and rpi hey there, thanks! may i ask if you use 0.47? i usually get error msgs also without the -stderr , will using it give me more information?
On Sun 15. Sep 2019 at 19:04, Christof Ressi christof.ressi@gmx.at wrote:
Hi,
im attempting to use (pd~) in a patch in order to use multicore
processing on my rpi 3b+.
I do this all the time and never had a problem... do you get any errors? since you run headless you might start Pd with "-stderr" to see the error messages in the terminal.
should i go thru the trouble of compiling / installing a newer version
compiling Pd on the raspberry pi is actually quite easy.
Christof
*Gesendet:* Sonntag, 15. September 2019 um 18:57 Uhr *Von:* "iftah gabbai" ift.gab@gmail.com *An:* "pd-list@lists.iem.at" pd-list@lists.iem.at *Betreff:* [PD] pd~ and rpi hello list, its my first email ever so i really hope i do the guidelines justice, i just missed the part about the gmail issue so chaned my adress to @googlemail , apologies if u got this email twice :)
i tried searching the list and google and couldn’t find too much info so i try here: im attempting to use (pd~) in a patch in order to use multicore processing on my rpi 3b+. it works fine on my mac using pd 0.50 but does not seem to work on my rpi running strech lite headless and pd 0.47. the closest i got is to get it to print info out of stdout and this is happening only when i start the dsp in the sub process which kinda contradicts the documantaion. i tested also using atest patch which is just an osc~ connected to a dac~ in the sub process but still no luck. i wonder if anyone ever got this to work? is it related to 0.47 and should i go thru the trouble of compiling / installing a newer version since 0.47 is the latest version available for strech lite as far as i understated?
thank you very much _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Am 15. September 2019 20:45:07 MESZ schrieb iftah gabbai ift.gab@gmail.com:
im sshing and viewing it via terminal, no error msgs whatsoever, with or without the -stderr, i tried to compile 0.49 a couple of days ago and got
strech lite headless and pd 0.47.
how about using buster? it comes with Pd-0.49 (i always find it weird that people complain about Debian having too old versions of software, while at the same time they will only install the oldest Debian releasr they can get their hands on)
mfg.hft.fsl IOhannes
not sure i complained, but ill give it go anyways :)
On Sun 15. Sep 2019 at 21:02, IOhannes m zmölnig zmoelnig@iem.at wrote:
Am 15. September 2019 20:45:07 MESZ schrieb iftah gabbai < ift.gab@gmail.com>:
im sshing and viewing it via terminal, no error msgs whatsoever, with or without the -stderr, i tried to compile 0.49 a couple of days ago and got
strech lite headless and pd 0.47.
how about using buster? it comes with Pd-0.49 (i always find it weird that people complain about Debian having too old versions of software, while at the same time they will only install the oldest Debian releasr they can get their hands on)
mfg.hft.fsl IOhannes
Am 15. September 2019 21:06:55 MESZ schrieb iftah gabbai ift.gab@gmail.com:
not sure i complained, but ill give it go anyways :)
sorry. *you* certainly did not complain.
i still wonder why you installed stretch instead of buster.
mfg.hft.fsl IOhannes
I remember this bug. 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. A simple
[loadbang] | [; pd dsp 1(
[loadbang] | [delay 1000] | [; pd dsp 0(
in the subprocess will make it work. I'm not sure if or when this was fixed, but I think it was at some point.
On 15.09.19 18:57, iftah gabbai wrote:
hello list, its my first email ever so i really hope i do the guidelines justice, i just missed the part about the gmail issue so chaned my adress to @googlemail , apologies if u got this email twice :)
i tried searching the list and google and couldn’t find too much info so i try here: im attempting to use (pd~) in a patch in order to use multicore processing on my rpi 3b+. it works fine on my mac using pd 0.50 but does not seem to work on my rpi running strech lite headless and pd 0.47. the closest i got is to get it to print info out of stdout and this is happening only when i start the dsp in the sub process which kinda contradicts the documantaion. i tested also using atest patch which is just an osc~ connected to a dac~ in the sub process but still no luck. i wonder if anyone ever got this to work? is it related to 0.47 and should i go thru the trouble of compiling / installing a newer version since 0.47 is the latest version available for strech lite as far as i understated?
thank you very much
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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.
@iftah, some more ideas:
- make sure DSP is turned on in the parent process (even if the subprocess doesn't process audio)
- make that the subprocess could really load the patch (verify with the GUI)
- in the subprocess, send a message to [stdout] with [loadbang] and check if you receive it in the parent process
- send a message to the subprocess and check if it is properly received, e.g. by sending it back to [stdout]
Christof
Gesendet: Montag, 16. September 2019 um 12:35 Uhr Von: "Max" abonnements@revolwear.com An: pd-list@lists.iem.at Betreff: Re: [PD] pd~ and rpi
I remember this bug. 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. A simple
[loadbang] | [; pd dsp 1(
[loadbang] | [delay 1000] | [; pd dsp 0(
in the subprocess will make it work. I'm not sure if or when this was fixed, but I think it was at some point.
On 15.09.19 18:57, iftah gabbai wrote:
hello list, its my first email ever so i really hope i do the guidelines justice, i just missed the part about the gmail issue so chaned my adress to @googlemail , apologies if u got this email twice :)
i tried searching the list and google and couldn’t find too much info so i try here: im attempting to use (pd~) in a patch in order to use multicore processing on my rpi 3b+. it works fine on my mac using pd 0.50 but does not seem to work on my rpi running strech lite headless and pd 0.47. the closest i got is to get it to print info out of stdout and this is happening only when i start the dsp in the sub process which kinda contradicts the documantaion. i tested also using atest patch which is just an osc~ connected to a dac~ in the sub process but still no luck. i wonder if anyone ever got this to work? is it related to 0.47 and should i go thru the trouble of compiling / installing a newer version since 0.47 is the latest version available for strech lite as far as i understated?
thank you very much
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
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 ¯_(ツ)_/¯
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
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 ift.gab@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@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
indeed, i guess i misunderstood altho im pretty sure i was getting sound without turning on the dsp on my mac, i will check that and report back
On Mon, Sep 16, 2019 at 9:45 PM Christof Ressi christof.ressi@gmx.at wrote:
or at least on my system and in contradiction to the documentation the
dsp in the sub process MUST be on.... otherwise no sound
actually, in the documentation it says:
"We turn DSP on at load for convenience - control objects in this patch will still work without it (unlike in the super-process, where DSP must be on for time to move forward in the sub-process.)"
this doesn't imply that you don't need to turn on DSP for audio objects - on the contrary!
But are you saying on your Mac you got sound *without* DSP being turned on in the subprocess!? This would surprise me...
Christof
*Gesendet:* Montag, 16. September 2019 um 21:18 Uhr *Von:* "iftah gabbai" ift.gab@gmail.com *An:* Max abonnements@revolwear.com *Cc:* Pd-List pd-list@lists.iem.at *Betreff:* Re: [PD] pd~ and rpi 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 ift.gab@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@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
_______________________________________________ Pd-list@lists.iem.at
mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
iftah gabbai -
IOhannes m zmölnig -
Max