problem with msp-calculations: they restart always when chaning sth

What you are trying to do is very hard. When you add a new object, Max may need to rebuild the DSP chain, which might alter existing values or create clicks in the audio.

I don't think Max is meant to be a real time performance patching environment.

You can fake it by revealing hidden MSP objects, and simultaneously allow them to function (add to the signal chain) via a matrix~ or somesuch. Since they were there already, though not adding any signal level, there won't be clicks. It's not really "live patch-building" but the idea might be good enough.

@seejayjames: thank you for this hint, but unfortunately it doesn't fit with my concept, because the main idea for this piece is to improvise in creating new and not already built patches. anyway, a few objects are ready-made, but it's still my decision, if I want to built it into my empty patch.

> What you are trying to do is very hard. When you add a new object, > Max may need to rebuild the DSP chain, which might alter existing > values or create clicks in the audio.

yes, that seems to be exactly the problem. it also happens, when you just add/remove a patch chord. Is there no way to avoid this problem in this situation?

You might also want to have a look to poly~. You can dynamically load patchers without causing audio interruptions.

Although this possibility of poly~ is very good, I don't think, that it will take me to where I want to be. I already messed around a little bit with poly~, but this special function is new to me. If there is no other way to get rid of the clicks, I'll use a sound layer of arrythmic impulses to hide the clicks (more or less) ;)

You could try ducking the volume on your master output when you create something new, not the best workaround I'm sure, but it would hide the clicks.

lh

have you considered that your concept sucks? ie, the point of 'live-coding' (whatever that is - i live-code, just not in front of an audience) is that it is a 'warts-and-all' art form. if the software with which you choose to live-code has this behaviour, that is what the art you make with it will embrace? ie, the soundforms will involve clicks, restart of dsp chain, etc. as far as audio refinement goes, from what i gather you would be better off using Supercollider and/or Pd for this project.

EDIT - OUCH! sorry about that... should not reply to posts before my morning coffee...

pid, out of curiosity, why do you think PD would be suitable for this?

@pid of course I recognize the problems of max/msp considering live-coding. I already also live-coded with SC, and my attempt was now to try something similar with max. also, i don't think that this concept sucks, because we will be four people live-coding and improvising together at the same time (with different environments). of course, if there is no possibility to avoid the restart of the dsp-chain (i'm getting the feeling that this is really something you can't change in max), then it's ok. like you said: 'warts-and-all' art form. But maybe I'll take a deeper look at Pd (I just did some tests, and it seems that there is no restart of the dsp-chain).

>(i'm getting the feeling that this is really something you can't change in max)

Yep. That's exactly right. At this time, anyway.

@Gregory Taylor thank you for this clear answer. So now I can stop to search for some "hidden" options :)

anyway, i now decided to use max/msp in my live-coding performance. one of my band members said: "it's like the chiffs on wood winds". it's just a characteristic of this instrument. if someone is interested: We will perform in Karlsruhe, Germany at the ZKM on Fri 22 January (http://on1.zkm.de/zkm/stories/storyReader$6962 ).

Actually, there is a way to handle the specific example you cite. Cycle~ resyncs when the DSP chain is rebuilt, but phasor~ does not. So use a phasor~ driven cycle~.

Here's an example: