hi crew. i was just wondering if anybody has made a patch that can be used to open and close other patches one after each other on the fly. i want to be able to do a whole performance without touching my mouse and using just assigned midi controlers but a have lots of patches for different pieces. cheers tom.
Hallo, tdunstan@ihug.com.au hat gesagt: // tdunstan@ihug.com.au wrote:
i was just wondering if anybody has made a patch that can be used to open and close other patches one after each other on the fly. i want to be able to do a whole performance without touching my mouse and using just assigned midi controlers but a have lots of patches for different pieces.
There are the so called "Internal messages" to Pd. You can find a link to them at http://www.pure-data.org/docs and also in the CVS.
But beware: IMO it is not a good idea to open any patches while a performance is running. It may disturb the audio stream. So unless you pause between pieces, I guess you shouldn't risk this.
This brings me to another question:
I'd be interested in how the live performers here handle this. What do you do when you have to play for several hours? Do you just use one large patch with loads of abstractions that get [switch]ed on and off?
Please tell your secrets, enlighten us!
ciao
Frank Barknecht _ ______footils.org__
At 06:55 AM 4/11/2003, Frank Barknecht wrote:
I'd be interested in how the live performers here handle this. What do you do when you have to play for several hours? Do you just use one large patch with loads of abstractions that get [switch]ed on and off?
In the past, I have had to play for 20 minutes. Mind you this was with 2 keyboards and a MIDI controller. Pd was just the core of the performance, controlling sound volume, accompanyment playback, and also a click track for others that I was playing with. Unfortunately I don't have the patch any more as stated earlier, due to a hard disk crash, but from memory, I used the pgrmin object from one of my controllers to adjust various elements of the MIDI routing somehow.
I may be trying to do the same thing soon, so if anybody is interested, I will post the patch.
Luke
Luke Yelavich AudioSlack Founder and head package maintainer Audio software packaged for the Slackware Linux Distribution http://www.audioslack.com luke@audioslack.com
Hallo, Luke Yelavich hat gesagt: // Luke Yelavich wrote:
At 06:55 AM 4/11/2003, Frank Barknecht wrote:
I'd be interested in how the live performers here handle this. What do you do when you have to play for several hours? Do you just use one large patch with loads of abstractions that get [switch]ed on and off?
I may be trying to do the same thing soon, so if anybody is interested, I will post the patch.
Was this patch used for several pieces in those 20 minutes? At home I tend to use several patches, more like one patch per track. But this is hard to get on stage (not that I used Pd on stage yet), because you have to deal with loading times and possibly interruptions. So I wonder, if people tend to build special performance patches, how they cope with tracks that need highly different material.
ciao
Frank Barknecht _ ______footils.org__
i have one set of abstractions that i use for all my performance.. usually i build the patch out of those abstractions before the performance based on how i want to play that specific show. to account for different songs needing different things i usually choose to simplify/interperate the song to match the patch that i'm using. i don't worry too much about having the performance sounds like the recording, as long as it's interesting and engaging then it doesn't matter if this sound is a little different than that sound....
i do use pd exclusively for performance because of the flexibility ... there is the occasional millisecond dropout, but that's just the nature of electronic music performance right now. i find on os x using the -rt flag helps to reduce dropouts due to gui activity.
matt.
On 3-Nov-03, at 5:18 PM, Frank Barknecht wrote:
Hallo, Luke Yelavich hat gesagt: // Luke Yelavich wrote:
At 06:55 AM 4/11/2003, Frank Barknecht wrote:
I'd be interested in how the live performers here handle this. What do you do when you have to play for several hours? Do you just use one large patch with loads of abstractions that get [switch]ed on and off?
I may be trying to do the same thing soon, so if anybody is interested, I will post the patch.
Was this patch used for several pieces in those 20 minutes? At home I tend to use several patches, more like one patch per track. But this is hard to get on stage (not that I used Pd on stage yet), because you have to deal with loading times and possibly interruptions. So I wonder, if people tend to build special performance patches, how they cope with tracks that need highly different material.
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
/* Matt Nish-Lapidus
www.ekran.org/mn-l matt@ekran.org // mattn-l@rogers.com
"What's this fish doing in my ear?" */
Matt, have you finally shed yourself of that Mr. Hyde Control Freak side of your personality?
Let me congratulate you. :P
David
. . David McCallum . Music wants to be free . http://mentalfloss.ca/sintheta .
Matthew Nish-Lapidus wrote:
i don't worry too much about having the performance sounds like the recording, as long as it's interesting and engaging then it doesn't matter if this sound is a little different than that sound....
At 09:18 AM 4/11/2003, Frank Barknecht wrote:
Was this patch used for several pieces in those 20 minutes? At home I tend to use several patches, more like one patch per track. But this is hard to get on stage (not that I used Pd on stage yet), because you have to deal with loading times and possibly interruptions. So I wonder, if people tend to build special performance patches, how they cope with tracks that need highly different material.
Yes. The patch was basically an audio and MIDI router. I was using Pd with JACK, and had one keyboard's audio into the computer, and ZynAddSubFX acked into Pd as well. The sounds on the keyboard weren't being changed, but I was using the programme change ability on the other keyboard to send Pd messages to change the sound that ZynAddSubFX was playing, by simply changing the channel the MIDI data was sent to.
The ZynAddSubFX patch was set up with the various sounds I wanted to receive on different channels.
I ended up having problems with this, as ZynAddSubFX kept on zombifying, as a JACK client. But that was the theory.
I intend to go back and see if I can make it work a bit more stable, and it would be handy if I still had the patch...
Luke
Luke Yelavich AudioSlack Founder and head package maintainer Audio software packaged for the Slackware Linux Distribution http://www.audioslack.com luke@audioslack.com
I'd be interested in how the live performers here handle this. What do you do when you have to play for several hours? Do you just use one large patch with loads of abstractions that get [switch]ed on and off?
there are quite some dropout issues with pd when playing live: open (sub-)patches, load soundfiles to buffers, gui-actions under high load (eg. drawing in arrays)...
my personal approach to computermusic is to explore errors and glitches so pds little disadvantages are welcome and i try to play with them. i think a live-performance at the edge of crashing can give interesting results, but this can't be a general approach.
correct me if i'm wrong, but as far as i can judge pds architecture these issues are fundamental design problems about the way pd does (not) use threads and does (not) seperate gui-, file- and signal computation.
i fear, if you want to be on the safe side, either you have to *) be very careful when loading files or fiddling around with patches+guis or *) additionally use other/external sound-sources to camouflage the problems. or *) use extremly high latencies and buffers and pray.
:(
regards d13b
At 09:03 AM 4/11/2003, d wrote:
correct me if i'm wrong, but as far as i can judge pds architecture these issues are fundamental design problems about the way pd does (not) use threads and does (not) seperate gui-, file- and signal computation.
The only thing that I am aware of with Pd using multiple threads is when used with JACK on Linux, as Jack's design requires a separate processing thread. Not sure about other areas of Pd though.
Luke
Luke Yelavich AudioSlack Founder and head package maintainer Audio software packaged for the Slackware Linux Distribution http://www.audioslack.com luke@audioslack.com
The only thing that I am aware of with Pd using multiple threads is when used with JACK on Linux, as Jack's design requires a separate processing thread. Not sure about other areas of Pd though.
i do use pd+jack+linux for a while now because jack offers great possibilities, but i guess low-latency realtime audio always has to be seperated from other functionalities to work smoothly.
i think that pd should be able to load a simple soundfile into an array without blocking for ages. also i think it should be possible to draw a line in a graph/array without making the whole application stutter.
there are workarounds and one can learn to avoid situations, but ideal would be a pd taking care of such things.
regards d13b
At 10:09 AM 4/11/2003, d wrote:
i think that pd should be able to load a simple soundfile into an array without blocking for ages. also i think it should be possible to draw a line in a graph/array without making the whole application stutter.
I haven't used this functionality in Pd as of yet, but it could have a lot to do with system resources as well.
there are workarounds and one can learn to avoid situations, but ideal would be a pd taking care of such things.
In terms of graphical work on screen while audio is being played, Ardour is a good example, and seems to handle it well.
Luke
Luke Yelavich AudioSlack Founder and head package maintainer Audio software packaged for the Slackware Linux Distribution http://www.audioslack.com luke@audioslack.com
Switch~ is a friend. I also use csound~ for a lot of sound generation, and load different orc and scores with this. I do use a dual processor machine, so maybe that is why I don't have many glitches or problems with loading in the middle of pieces.
Generally there are small pauses between pieces (applause?) in the kind of venues I play, so loading a new patch is also not a problem in that case.
On the other hand, I am trying to focus my main performance patch to a kind of limited generality similar to a tradional musical instrument. That is my background, and I don't change instruments every piece if I play acoustically.( I only know how to play 1.5 of those anyway)
But overloading a csound instance with a granular score to create digital noise is nice. Especially towards the end as the computer catches up and the noise disintergrates into a pure tone.
Gerard
On Monday 03 November 2003 19:55, Frank Barknecht wrote:
I'd be interested in how the live performers here handle this. What do you do when you have to play for several hours? Do you just use one large patch with loads of abstractions that get [switch]ed on and off?
Please tell your secrets, enlighten us!
ciao
On Mon, 2003-11-03 at 14:55, Frank Barknecht wrote:
Please tell your secrets, enlighten us!
In some of the shows my performance consists of very diversified pieces for which I use different software: ecasound, pd (different patches), terminatorX, freqtweak. Not all of them together, though.
I basically have a jack server running and everything plugs and unplugs from Jack (I run tX with jacklaunch but apparently a new version is jackified?). The whole thing is orchestrated by RTmix. Some things load faster, others slower so sometimes there is a little gap between pieces but usually it isn't a problem. Sometimes I mange to overlap 2 things. Sometimes I use up to 3 guitars (no, not at the same time) so the loading time of patches is roughly equivalent to the time of changing the instrument.
I call the apps with all necessary command line switches so I don't have to tweak anything once the app is open.
-
d -
David NG McCallum -
Frank Barknecht -
Luke Yelavich -
Matthew Nish-Lapidus -
Michal Seta -
tdunstan＠ihug.com.au -
vanDongen/Gilcher