Hi,

For the last 6 months, I've been using Pd for playing live sets, in the following way.

I have a master set patch, that load the track in the set as separate patches, each with their own switch~ statements, and midi switches (basically, if you aren't switched on, then you won't receive any midi signals, but when you are you do. This is done with the help of the $0 functionality). This way I can use one or two controllers and a mixer to control each track separately, but not have the controls of what I'm doing in one track effect the other tracks.

Because of this, I can only play a track, fade it out to silence, then turn other the next track (something do with with synching of switch~ between patches causes clicking and noise). I want a way of playing track one after the other without having to fade the other tracks out, more like a proper set.

Any suggestions on what I can do? (ex. can I make subpatches have their own $0 value for example. I understand that abstractions have a seperate $0 value, but it doesn't make much sense to make a track as an abstraction.)

Thanks,
Kris

i think if you're getting clicks, then you might be running into trouble with your [switch~] timing. What you ideally want, is for one subpatch to be turned off and then for the other one to turn on at that exact same instance.

I'm not exactly sure how switch~ works with block boundaries, but i THINK what happens is that it will turn on immediately when sent a [1 ( message, but it will wait until the end of the block to turn off when sent a [0 ( message.

so, in that case, if you send the on and off messages to both subpatches at once, you'll get a fraction of a block in which both patches are overlapped.

You might be able to work out some way to avoid this. My suggestion would be to try [bang~] in your first subpatch, to trigger the [1 ( message to start the 2nd subpatch.

If I'm not mistaken, [switch~] does conform to block boundaries for both on and off. I would suggest having a switched-on patch fade in and a switched-off patch fade out when receiving the message for a couple of milliseconds. A block size of 64 is about 1.4 ms at 44.1 kHz, so anything longer than that should avoid clicks.

I prototyped a similar idea a while ago for a class project, except the tracks were actually abstractions that took clock timing from the main patch. My implementation had some flaws, and I've been meaning to have a second go at it. But in that version, the main patch had a crossfader, and the tracks were associated with different ends of the crossfader. It allowed the transitions to be whatever pace I wanted. It meant that the two patches were running at the same time during the fade, of course, but it also allowed some flexibility. Just some food for thought.

"it doesn't make much sense to make a track as an abstraction"

why not?

@Psyko said:

"it doesn't make much sense to make a track as an abstraction"

why not?

Good point. I mean if using abstractions will get over the issue then I should do it. I could also be a problem with the block size. I`m running 96khz so maybe I need a larger block size (though I never really understood the block math).

Thanks for your suggestions. I`ll go try a few things out and see how it goes.

Something else to consider. If you're tracks all have unique names, you could use the name to identify sends/receives etc. instead of $0. This would probably make your code more readable, and allow you to send messages from anywhere to your tracks.

An extension of this idea would be to create a [song] abstraction whose first argument would be the song title. Then you could just use $1 instead of $0, and still access the tracks parameters from anywhere by title.
Another benefit of this method is that [song] could contain sends/receives that talk to the parent patch, for things like tempo, time syncing, etc. And you wouldn't have to rewrite things like your clock, sequencers, and input/output every time you wrote a new song.

Just some ideas. I have no idea what your workflow is like, so I don't know if this helps or not.

I think you are thinking on the right track, Psyko Logical, but I personally think it is always a good idea to think that there might be the (perhaps rare) possibility that you might have two instances of the parent patch running at once, or another unrelated patch running along side it (say, a separate synth to jam with over the track). In my implementation, $1 was actually $0 of the parent patch. This made grabbing something like the clock timing from the parent patch easy, as you could have a [r $1-metro] grabbing from the from the parent patch. And it wouldn't interfere with the other patch that just might happen to have a , or even a .

I've found it is best to ALWAYS use $0 in [send], [receive], table names, etc. to avoid any potential conflicts. I do it by default. And if you have an abstraction that requires [send], etc. to communicate with the parent, just send $0 along as an argument. It can sometimes make things difficult to keep track of, but in the long run, you won't run into cross-talk issues, and you can thus run any of your patches concurrently without problems.

mmb-
I think of it a lot like access modifiers in other languages. $0 is for private fields, $1 is for public. Often times $1 will contain its parent's $0, but still followed by some sort of descriptive name.
Instead of sends and receives I use an abstraction based around the value object, which also allows me to think in a more 'classical' manner. Fields can be accessed as needed by name and it combines s/r functionality into one parameter object.
I also have everything built around a single 'global' patch with a subpatch called [interface] that contains all the parameter objects used globally, for easy reference and copying. In fact, each object created for use in this environment contains it's own [interface]. This way, when creating a new object, I know I can just type something like [x TEMPO] and be sure it's using the same tempo as everything else, and that any change to tempo anywhere will be recognized as it happens.

But this is a little deeper than ksujata was looking for I think.
It really all boils down to preference, and what you can make pd do for you.