[ossia-max] : how to declare sub-multiple in nested models

[vincentgoudard]

I have the following problem that got me pulling some hair.

I want to instancitate a series of model that describe a multichannel, multiband limiter.

• The top-level model name would be myLimiter.
• It contains a sub-model for channels that could be name as channel.{1..K} (for K channels)

Then I could name my submodel for channel band.{1..L} (for L frequency bands), just like I did for channels, except I may want a different number of bandcounts per channel and the brace expansion channel.{1..K}/band.{1..L} would result in the same number of bands for all channels.

So, on way would be to give a full length address to my "band" model, like :

myLimiter/channel.{1/band.{1..3} | 2/band.{1..64} | 3/band.{1..12} | 4/band.{1..5}}

but that's not a super-convenient way of doing, because it requires you to parse the full path and intertwine channel- and bandcounts.

So what I came up with is the following idea : sending a series of addresses to a model would dispatch them on the parent model's. For instance, if you have a parent model for channel that was declared as channel.{1..3} and you send the following series of addresses on a submodel : band.{1..2} band.1 band.{1..5} , they would be dispatched so that :

• band.{1..2} is expanded on address channel.1
• band.1 is expanded on address channel.2
• band.{1..5} is expanded on address channel.3

Any thoughts on this ?

[avilleret]

hum and then what happen when you change the number of channels ? from 3 to 5 for example, how many band will have the channels 4 and 5 ?

I think I already faced kind of similar issue and to solve it, I would add a parameter band_count with higher priority (so it is recalled first) that set the band count on each channel

[vincentgoudard]

Well, the list of band.{1..n} addresses is being generated by the bandcount parameter, so all the channels would get a corresponding "band" submodel address. This way we ensure consistency between the channel count and the number of (brace)adresses you give to the "band" model.

As far a scheduling is concerned, I prefer not to rely on priority, as patchers may involve some asynchronous operations. In my libossia ersatz, when I recall a preset, the data is being both sent to existing parameters and bufferized, so that any non-yet-existent parameter that get instanciated by an upper-level one (as is the case in the example above), can fetch its value from it.

Last, in cases where the consistency between parent model addresses and the size of the submodel address list, you can have strategies to dispatch them nicely.

Typically, if you have only one band address in your list, it would be applied to all channels. If you have two, the two first channels would be mapped, then the 3rd band would fold to the first channel. That is, if you have 3 channels and send a size-2 list like : band.{1..2} band.1 , they would be dispatched so that :

• band.{1..2} is expanded on address channel.1
• band.1 is expanded on address channel.2
• band.{1..2} (the 1st item) is (also) expanded on address channel.3