What would be a good configuration to avoid surprises in the LiveCoding sessions?

Questions
1

Hello,
I’ve been thinking about what is the best approach to do Live Coding. I’ve read and seen a lot of information but I don’t see it clearly.
I’m going to quote the ones I’ve been using:

  • Pdef is used to define event patterns that can be changed and controlled in real time.
  • Combining Tdef and Ndef allows us to create musical patterns and sound structures that are dynamic and controlled in real time, which I find very powerful for algorithmic composition.
  • ProxySpace is the one I use most often combined with Pdef and Pbind.
    With this approach I also use ~a.play; ~a.awake_(false) together with a ~a function (when I use this kind of syntax I have several functions prepared beforehand that I use as sound material.
    I have no experience in LiveCoding at the moment, but I’m going to launch my first sessions soon.
    What is the most flexible and dynamic approach of all these options? And by the way I would like to ask the question of the synchronization of the different functions, patterns, synthdefs, etc… what would be a good configuration to avoid surprises in the LiveCoding sessions?
    Good Sunday to all!!!
2

Almost forgot this thread… I don’t have a direct answer, but I think a key concern in live coding performance is to set up mechanisms to validate input before they reach a synth or sequencer. My specific approach to that might not be what you’re looking for, but… I’m using what are effectively wrapper objects around patterns, where the wrappers check for certain failure conditions at construction time (things like, this parameter should be a number or number-like thing – if it isn’t, then it throws an error before trying to execute the new behavior). You can’t catch everything in advance, but if you can cover a lot of common mistakes, it will reduce failures onstage.

I also put a bad-values check into my mixer synths (individual channels, not just a main-output sanitizer). This has concretely saved a few sets where DWGPlucked started giving NaNs.

I personally don’t think Pdef does enough to protect you against onstage bloopers – and you will make bloopers, no matter how much you practice. So that’s my main suggestion – build some helper objects to catch mistakes before they get into a running Pdef.

hjh

3

I seem to understand superficially what you explained but could you exemplify to understand how you implement these objects ? Thanks

4

How I implement it is more than just a couple wrapper objects – see this live set with all custom sequencing syntax and a “generator” concept that is related to patterns, but different from patterns as well. So at this point, I’m not using patterns directly for live coding.

If I were, I might try something like:

Psq {
    *new { |list, repeats = 1, offset = 0|
        if(list.size == 0) { Error("list should be nonzero size").throw };
        if(repeats.isNumber.not or: { repeats <= 0 }) { Error("Invalid repeats").throw };
        if(offset.isNumber.not) { Error("Invalid offset").throw };
        ^Pseq(list, repeats, offset)
    }
}

One other thing I did in my system is to treat numbers as “number proxies” so that I can write 4, 1..4 or {rrand(1,4)} interchangeably. That could make number validation a bit more flexible.

hjh