Hi, im back learning pd/max. Im playing with both Pd-extended and Max 6, I know that i must choose one, at least in this stage : ) Im interested in midi control but also in visuals, VJing and audio visual interaction. Currently im trying the simplest idea that crossed my mind, controlling some effects in gem with data from a peakamp. I have glitches and the audio pauses when i move the windows (specially the Gem window), is this normal? if i set up an environment with 2 screens (the case in a gig) can i freely manipulate the patches without fear? thanks
Based on what you said, one solution would be to run 2 Pd instances. Have one only generate the audio. Manipulate it using the 2nd patch (the one you will directly manipulate) using netsend/netreceive. This works especially well if your CPU has more than one core. It could be [pd~] could address your problem as well, but I haven't had as good luck with that approach. Or maybe if you made the audio latency high enough it would help, if latency is not an issue for you.
On Fri, Mar 15, 2013 at 11:09 PM, Jm Jones juanmjv@gmail.com wrote:
Hi, im back learning pd/max. Im playing with both Pd-extended and Max 6, I know that i must choose one, at least in this stage : ) Im interested in midi control but also in visuals, VJing and audio visual interaction. Currently im trying the simplest idea that crossed my mind, controlling some effects in gem with data from a peakamp. I have glitches and the audio pauses when i move the windows (specially the Gem window), is this normal? if i set up an environment with 2 screens (the case in a gig) can i freely manipulate the patches without fear? thanks
-- Juan Manuel Jones
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There have been discussions about the latest Pd being able to play video and audio without drop outs or glitches...haven't tried something like that yet though. Anyway, why do you need to move windows around? Especially the Gem window. During a performance or installation or whatever, why should the Gem window move?
On Sat, Mar 16, 2013 at 4:04 PM, John Harrison john.harrison@alum.mit.eduwrote:
Based on what you said, one solution would be to run 2 Pd instances. Have one only generate the audio. Manipulate it using the 2nd patch (the one you will directly manipulate) using netsend/netreceive. This works especially well if your CPU has more than one core. It could be [pd~] could address your problem as well, but I haven't had as good luck with that approach. Or maybe if you made the audio latency high enough it would help, if latency is not an issue for you.
On Fri, Mar 15, 2013 at 11:09 PM, Jm Jones juanmjv@gmail.com wrote:
Hi, im back learning pd/max. Im playing with both Pd-extended and Max 6, I know that i must choose one, at least in this stage : ) Im interested in midi control but also in visuals, VJing and audio visual interaction. Currently im trying the simplest idea that crossed my mind, controlling some effects in gem with data from a peakamp. I have glitches and the audio pauses when i move the windows (specially the Gem window), is this normal? if i set up an environment with 2 screens (the case in a gig) can i freely manipulate the patches without fear? thanks
-- Juan Manuel Jones
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2013/3/16 Alexandros Drymonitis adrcki@gmail.com:
though. Anyway, why do you need to move windows around? Especially the Gem window. During a performance or installation or whatever, why should the Gem window move?
Well, im testing the software to know what can/cant do. And I wanted to know if some behavior was normal or maybe a fault in my configuration. Anyway, Im testing Gem window creation in another screen via offset command, and i can move the patches windows without problems. To move patches windows (not the gem one) during performance seems a must! But as I said, it works ok. I was just reading a Max tutorial and i discovered the overdrive option that gives priority to the data procesing over the graphics, its seems that even with powerful computers this task is a difficult one.
On Sat, Mar 16, 2013 at 4:04 PM, John Harrison john.harrison@alum.mit.edu wrote:
Based on what you said, one solution would be to run 2 Pd instances. Have one only generate the audio. Manipulate it using the 2nd patch (the one you will directly manipulate) using netsend/netreceive. This works especially well if your CPU has more than one core. It could be [pd~] could address your problem as well, but I haven't had as good luck with that approach. Or maybe if you made the audio latency high enough it would help, if latency is not an issue for you.
On Fri, Mar 15, 2013 at 11:09 PM, Jm Jones juanmjv@gmail.com wrote:
Hi, im back learning pd/max. Im playing with both Pd-extended and Max 6, I know that i must choose one, at least in this stage : ) Im interested in midi control but also in visuals, VJing and audio visual interaction. Currently im trying the simplest idea that crossed my mind, controlling some effects in gem with data from a peakamp. I have glitches and the audio pauses when i move the windows (specially the Gem window), is this normal? if i set up an environment with 2 screens (the case in a gig) can i freely manipulate the patches without fear? thanks
-- Juan Manuel Jones
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandros Drymonitis -
Jm Jones -
John Harrison