Diemo Schwarz

Hi and sorry for the probably naive question (just getting curious about gen):

Is there a way to programmatically multiply parts of a gen patch, similar to what poly~ does, while staying inside one gen instance?

Use case: a cross-modulating oscillator bank.

Hi and sorry for the probably naive question (just getting curious about gen):
Is there a way to programmatically multiply parts of a gen patch, similar to what poly~ does, while staying inside one gen instance?
Use case: a cross-modulating oscillator bank.

equivalent-of-poly-for-gen-multiplying-gen-subpatches

It's actually not so simple, because when you copy a gen subpatch, you have to connect all the params with setparams to each one. Also, it does not do multithreading. Unless you are really serious, you probably want to stick with poly!

It's actually not so simple, because when you copy a gen subpatch, you have to connect all the params with setparams to each one.  Also, it does not do multithreading. Unless you are really serious, you probably want to stick with poly!


Thanks for your answer, Ernest! Sure, I wouldn't expect this to do multi-tasking, neither dynamic voice allocation.

 would generate the code in the subpatcher 

 times, and somehow expose params with indices or settable as a list, and make the current instance number accessible as a variable inside each instance.

I did read up on gen~ now, and find the lack of arguments for subpatchers and their substitution (#1) and generation and setting of the label for send/receive a real hindrance for this kind of genericity.

Thanks for your answer, Ernest! Sure, I wouldn't expect this to do multi-tasking, neither dynamic voice allocation.
Ideally, such a hypothetical multigen would generate the code in the subpatcher n times, and somehow expose params with indices or settable as a list, and make the current instance number accessible as a variable inside each instance.

I did read up on gen~ now, and find the lack of arguments for subpatchers and their substitution (#1) and generation and setting of the label for send/receive a real hindrance for this kind of genericity.


As of Max 7.3.1, you *can* add arguments to subpatchers (and abstractions) in gen~:

Oh, and this also works on the gen~ itself:

Another way of repeating sections is to define them as functions in genexpr and then make multiple calls to them.

(But note: this won't work if placed within a for loop, for complicated reasons)

A while back I shared something using gendsp based on a single definition / multiple instantiation. It is not the easiest or most intuitive approach, but actually I use it quite regularly.

https://cycling74.com/forums/granular-in-gen/

A while back I shared something using gendsp based on a single definition / multiple instantiation. It is not the easiest or most intuitive approach, but actually I use it quite regularly. 

https://cycling74.com/forums/granular-in-gen/


Thanks Graham, that's totally awesome and perfectly on time! I must have missed it in the doc or release notes.

And, yes, the codebox eases that kind of reuse a bit. The dream now would be to be able to address in/out vars as an array like so

for (i = 0; i < numoutlets; i += 1)
  out[i] = subprocess(i, ...);


or what if outlets would be mirrored as a Data array?:

Thanks Graham, that's totally awesome and perfectly on time! I must have missed it in the doc or release notes.
And, yes, the codebox eases that kind of reuse a bit. The dream now would be to be able to address in/out vars as an array like so

Yes, Data is the way to go for this (and yes, I wish it too).

The dream of using a for loop to do this is unfortunately not likely to come true.

The main problem is that subprocess() can be stateful, by having History objects or other stateful operators such as phasor(), cycle(), etc, which require memory allocation up front to support each iteration distinctly. (Otherwise, all your filters and oscillators etc. will be the same one). The generic form of a for() or while() loop is unpredictable how many iterations are involved, and thus how much memory needs to be allocated. We don't want to allocate memory in the audio loop, especially if suddenly many hundreds of iterations are invoked. Only in the specific case of a constant, as in "for(i=0; i

BTW My own approach to solving this kind of problem is to use another language generate repetitive genexpr code.

The dream of using a for loop to do this is unfortunately not likely to come true. 

BTW My own approach to solving this kind of problem is to use another language generate repetitive genexpr code.


That's much easier to declare Params as arguments over wiring up Setparams, great improvement. Currently I have >200 params in SynthCore. . Is there a limit to the number of Params that can be declared as arguments?

No limit that I know of. I wonder if there's a limit to how much text you can write in a max box?

Thanks, Graham. Although I'm sure it may not be the answer that some folks wanted, I always enjoy those explanations that clarify WHY someone is challenging or impossible, since it pulls the curtain aside a little bit and lets us marvel at the pinions, escapements, and tourbillons operating within.

So far, I have not had any limits on what I can write in a *codebox". Don't know about text box. in gen~.

I also wanted to thank for increasing number of inputs. I can use 43 now (which is still not actually enough for synthcore, but it is a big improvement). I just wanted to note, Graham, when hovering over the last inputs on a codebox with 43 inputs, the numbers that show up in the hover box are corrupted. Also the inputs do not turn red in the editor over something like 20. I just mention it in case you want to have it fixed. The extra inputs do work though, so thank you.

So far, I have not had any limits on what I can write in  a *codebox". Don't know about text box. in gen~. 

 I also wanted to thank for increasing number of inputs.  I can use 43 now (which is still not actually enough for synthcore, but it is a big improvement). I just wanted to note, Graham, when hovering over the last inputs on a codebox with 43 inputs, the numbers that show up in the hover box are corrupted. Also the inputs do not turn red in the editor over something like 20. I just mention it in case you want to have it fixed. The extra inputs do work though,  so thank you.


Thanks again, Graham, for the clear reminder of the underpinnings of the translation model of gen.

I agree that this could be more clearly achieved by an explicit poly-like operator, but I think an even more easy way could be a resonably powerful macro expansion language (a bit more powerful than the C preprocessor, esp. adding recursion to expand a block of code n times, without going into the full and ugly complexity of C++ templates).

You hint at doing that externally, with what language?

Yes in fact I have a feature ticket explicitly for a macro language in genexpr. One smart enough to be hygeinic etc.

But in practice I have been having fun using parsing expression grammars to generate genexpr. It helps that a gen object handles expr message so it can be remote coded. Mostly I do this in a browser-based editor. For the grammars PEG.js is not bad. Actually I used it for a workshop at last year's live coding conference.

Yes in fact I have a feature ticket explicitly for a macro language in genexpr. One smart enough to be hygeinic etc.  

But in practice I have been having fun using parsing expression grammars to generate genexpr. It helps that a gen object handles expr message so it can be remote coded. Mostly I do this in a browser-based editor. For the grammars PEG.js is not bad. Actually I used it for a workshop at last year's live coding conference.


https://worldmaking.github.io/workshop_iclc_2016

Hoping to run this again at NIME this year.

If there were a way to multithread in gen~, then it would be incredibly more useful.

Actually it's unlikely it would be much different to gen in poly in practice.

Please can you help me understand how functions work in FOR loops? It seems normally a function works more like a method in an object-oriented language, with a new stateful instance created each time it is invoked. But inside FOR loops, mayb eit is not stateful, but does the same code then invoked, so it works more like a function as known in non OOPs worlds, where there is more a desire to reduce code size with functions?

Are there any changes in statefulness of Max's built-in objects inside FOR loops? For example, SAH and Latch,? I guess accum does not increment on loop iterations, but one can still write new values to history, and the most recent values will be available on the next sample clock?

Please can you help me understand  how functions work in FOR loops?  It seems normally a function works more like a method in an object-oriented language, with a new stateful instance created each time it is invoked. But inside FOR loops, mayb eit is not stateful, but does the same code then invoked, so it works more like a function  as  known in non OOPs worlds, where there is more a desire to reduce code size with functions?

Are there any changes in statefulness of Max's built-in objects inside FOR loops? For example, SAH and Latch,? I guess accum does not increment on loop iterations, but one can still write new values to history, and the most recent values will be available on the next sample clock?


You might have seen my application of what I've asked and learned about in this thread with a matrix~ like gen patch :

https://cycling74.com/forums/sharing-is-matrixing-obviously-matrix-in-gen/

It shows how cumbersome it is to write code requiring multiple instances of some subprocesses. Imagine the matrix32 version of this...

That's where a macro language could go a long way.

Also, the need to copy the audio inputs into a Data array in order to pass them into the subprocesses is suboptimal and could be so much easier: I'd suggest a global option for a gen patch to make in and out accessible as a Data array instead of in1, in2, out1, out2, etc. with additional attributes giving their number.

You might have seen my application of what I've asked and learned about in this thread with a matrix~ like gen patch :
https://cycling74.com/forums/sharing-is-matrixing-obviously-matrix-in-gen/

It shows how cumbersome it is to write code requiring multiple instances of some subprocesses. Imagine the matrix32 version of this...
That's where a macro language could go a long way.
Also, the need to copy the audio inputs into a Data array in order to pass them into the subprocesses is suboptimal and could be so much easier: I'd suggest a global option for a gen patch to make in and out accessible as a Data array instead of in1, in2, out1, out2, etc. with additional attributes giving their number. 

It's "lexical instancing". That is, if you defined a function "foo", then each instance of foo() in your code implies an instance of any state foo requires (including History, latch, sah, phasor, accum, etc.). So calling foo(foo(foo(foo(x)))) creates four independent instances, but below is only one instance, because the text "foo" appears only once:

In this situation a macro language would be fantastic (there are many others, as Diemo notes). I noted the idea of a macro language as a feature request a long time ago, but it seemed a bit esoteric for most people. I'm happy to give it a shot if it seems low overhead. I could sketch up a grammar for it, but what kinds of things would you want to see/be able to do? Before/after examples would be great. Thinking hygeinic would be great. I was thinking something LISP/Julia inspired.

I guess my concern is, when compiling a gen~ function, does Max really make a 'real' binary-level function, that is, does it create a stack frame and push the variables onto the stack? Or does it expand the function in place sort of like a macro as you say?

I guess my concern is, when compiling a gen~ function,  does Max really make a 'real' binary-level function, that is, does it create a stack frame and push the variables onto the stack? Or does it expand the function in place sort of like a macro as you say?


Sorry to bump this thread. Does that mean we cannot use function calls in for loops?

Yes you can use functions in for loops, but you have to bear in mind the 'lexical instancing' issue regarding state. That is, a function that declares its own state (like History) or which uses stateful operators (like cycle, phasor, etc.) will share that state over each iteration of the for loop. Which might or might not be what you wanted.

I guess I didn't reply to Ernest's question. The answer is yes, it make a 'real' binary-level function. Send an 'exportcode' message to gen~ and take a look ;-)

Yes you can use functions in for loops, but you have to bear in mind the 'lexical instancing' issue regarding state. That is, a function that declares its own state (like History) or which uses stateful operators (like cycle, phasor, etc.) will share that state over each iteration of the for loop.  Which might or might not be what you wanted.

I guess I didn't reply to Ernest's question. The answer is yes, it make a 'real' binary-level function. Send an 'exportcode' message to gen~ and take a look ;-)


It's a little bit tricky because a function may not use History or phasor explicitly but instead call functions that do so. Hence you need to make sure all functions in the chain of invocation is "clean" of state, am I right?

It's a little bit tricky because a function may not use History or phasor explicitly but instead call functions that do so.  Hence you need to make sure all functions in the chain of invocation is "clean" of state, am I right?


equivalent of poly~ for gen (multiplying gen subpatches)