Multichannel expansion/behaviour for objects with audio ins/outs

[Alex Harker]

There has been some confusion about how multi-channel works in relation to audio, and at the moment the behaviour is that inputs/outputs are shared. Therefore with a multi-channel input to fl.sink~ all inputs will paste to a single mono output channel. Similarly a multichannel input to fl.source~ will pull all the output from a single mono input channel.

This seems to me to be useful behaviour in some scenarios, but not others. In some scenarios it seems like outputting to (or drawing input from) separate channels would be helpful (at the moment you'd have to fl.unpack~ and use several fl.sink~ object to get multichannel outputs).

The solution I propose is that objects with audio ins/outs can be set to a certain number of "streams" (not quite the same as channels, because the internal object might have more than one channel of IO and these will be replicated for each stream). Frame streams will than be wrapped modulo against these audio streams, allowing both kinds of behaviour.

• does this work for you?
• how do you think the number of streams should be set?

1. by a parameter

2. by a parameter with an argument (which one?)

3. by a separate character/character sequence specific to the max wrapper

Thoughts appreciated.

[st kr]

Is there any problem with leaving source~ and sink~ as they are, and having additional multi objects? such as unpacksink~ and packsink~? At the moment I have to admit I am having problems wrapping my head around your explanation. As far as I can tell I would go just with argument(s). These are max-specific objects / ideas anyway?

[Owen Green]

Works for me. Not sure I fully appreciate the nuance of the different options for setting the number of streams. What are the consequences of any given choice?

Does this scheme mean that there would be an option for fl.read~ to pull more than one chann stream from a buffer? Or is that there already, and I'm being dim?

[Alex Harker]

Yes this probably isn't very clear. I suppose one idea is that you type ~4 into the object box and you then multiply the audio IO by 4 (so for fl.sink~ you'd get 4 outs, but you could drive them from one cable, removing the need for fl.unpack~ and 4 fl.sink~s which is tiresome for large channel numbers).

This stuff is not strictly max specific - there needs to be a mechanism in the underlying library for setting the number of streams, but then there is the way it is addressed in max which is separate. The issue with arguments/parameters is that the expander is a wrapper and currently just passes on params to the internal objects - splitting some off at the higher level is a problem to be solved).

[Alex Harker]

Owen - fl.read~ multichannel is a somewhat separate issue if you want to get synced frames, but that will be addressed when we get there...

[Francesco Cameli]

I think that the way things are now are quite straightforward with audio in/out objects. I see, though, how a specific multichannel behaviour would be needed. With the case of fl.sink~, it could be convenient to just type "fl.sink~ 4" to have four streams already unpacked. For the fl.source~ case, I would suggest to use a list of values to set the individual parameters of each stream. Something like: "fl.source~ 4 /size 512 1024 2048 4096". Would something like this, though, require to also rethink fl.frommax~, fl.interval~ and others? For example, fl.interval~ could be set as: "fl.interval 4 /interval 128 256 512 1024", and fl.frommax would have to unpack a Max list into different streams. So it would be, "(1024 2048 4096 8192) -> [prepend size] -> [fl.frommax~ 4 /mode params] -> [fl.source 4]". This would make patching way more concise, in certain situations.

[Alex Harker]

Unfortunately the expander is built on the assumption that all the internal objects have the same parameters at instantiation and working around that is a problem. That doesn't stop you externally packing together parameters and setting them differently in the hosted objects, but I don't think I'm going to support a way to set different parameters for different instances in a multichannel object. I think I'm going to make a versions with ~N for the next alpha see how it fits and then we can discuss whether the syntax is nice or not...

[Alex Harker]

Here's a quick example of how to do different intervals from a single fl.source~. There might also be some other objects that will make stuff like this easier.

I have been considering ways of synced interval cycles in objects also.

<pre><code> ----------begin_max5_patcher---------- 390.3ocyTFsaCBBEF9Z8ofv0tFADW6dUVZVnV1FaVzfXmMMsO6SNnocqYMZ8 h0ajv+4H+7AmC6CCvqJZjUXzSnmQAA6CCB.ImPP27.7FQSVtnBRCqkeUr5Cb jOjU1XA4WymUJx97HJoOTkcWtDh0qTJrYuqzu8hQlY8dR4jYwQHxBtafQotA 2WzxteRWuQoykVv8jNQ0ZXga2HOjhOkXQssOSRmpWxtqT5MDiQKcQNDF59DM YpUZqzrUjeDwIzQwNmm.ryA1mu35nStDc9cC5jX53t2S3ryXeQ5nYO4tgcZb x7QwNiSmF6r6F1ShWjdS862L6z+Y1qJpMYxiiCZpu2lA26orqCM6RnISBZvF btR+6G5gspS+mmDdD6Vpt2YPm1rqkUVkVXUE5yxosL.w9iy5g5Sx.8gNQeXC zGxD8gNPehmnOoCvGxE73KKDkkaklptjAKZaE9nv3l9XDLUo8SgJSrQtU0mO GTDl1Jdaa4dsw2KzL2+p.dSwZoQWqfp0PmyGB+lIu+NP -----------end_max5_patcher----------- </code></pre>

[st kr]

i have to ask (sorry) why the "~" ? i realise there would be argument ordering issues if it was just a number, but "~" seems really confusing to me, as looking at a patch one has to doubletake, with the ~ of the object followed by the ~ of the channels. please ignore me if you feel my musing is just an initial reactionary complaint and maybe i should just get used to it.

[Alex Harker]

I wanted to get something out to test fast and it was the idea I had. I'm not that attached to it as a notation. Please propose something better and I'll consider it.

[Alex Harker]

Does anyone want to propose a better notation for explicit multi stream expansion? I'm not really happy with the tilde....

[Owen Green]

What about < ? As in [fl.source <4]. Or maybe it's just really confusing (I was thinking it was like the similar operator in Faust)

[st kr]

actually i think the faust similarity could be a good idea.

[Alex Harker]

what about the case of fl.<~ <4 - doesn't that look confusing?

How would we feel about {4} (so in this case. fl.<~ {4})?

I dread to think what PA would think if I borrowed any ideas from Faust...

[st kr]

i think

fl.<~ <4

is not as bad as

fl.anything~ ~4

which happens all the time, as opposed to only sometimes.

brackets are terrible because they involve 200% more typing, and thus 109% more chance of bugs.

p .

[st kr]

p.s. - you can just tell PA it is an original concept.

[Alex Harker]

I think it's time for a "what are all the options" patch... I will write one presently and we'll do votes (with my veto obviously...)...

[Alex Harker]

<pre><code> ----------begin_max5_patcher---------- 508.3ocuW2sSCBCE..9Z3o.6kl4BsPYcl4E9+CgwXPrprLfEnnyrr8536gOY BsfgDmgY2gdyZ5osr9EZNG5ZaKziYq3EHmSctywxZsskkLTc.ql9VnjvUQKB KjSCkxeO6w4nQpgD7UBY3mWLtHqLOhu04HeGb63okIYkhEbgbw3lnEhOVvkK qcdKCEQuFm9xC47HgZ6P77F6NxgPo0Mr.YGxXWm6aVi5AK9XIWs.D5mgheR9 zq1nmfmzYuDm1tU7pisw1t9mQfQ+qOg0NAW2L0UW6LCZes+FHsiYSj1w5Zep AseLnu1wTYCioIchqAoeFrzwSOnS7DrAoOCT5L5gImXP4aAUN8vxxQ71o7.M jGkkjvSE+h9s6Fq6+AKl42odl5bNwsi1tIuB1IILfjtAPRpxT8PhN3jtFNRM Ue5gj+fS5J.IoppzCIuAmzk.RRgoGRjAmzEvQhsOYGvCtnygSDceRN3Bln+t 30LvtZB1k1IUNchlEt18MSHPiFpKkzpVksOP2OLOvLpg55HMpaJHDPzTM0Lp OFzW0MkLnS0DsuYPeFrnUopz97smYPOCTzpxNZalXFyaA0L8vxig60rbUnvk KeimWDmkJYWith77r75tSFI6Fmp55I6lyeKtc9TYjv7JChJ.k4JcqXpznnjr m34okwMkKq9m2X+MbREbhC -----------end_max5_patcher----------- </code></pre>

Please vote against letters!

[st kr]

this is extremely difficult to pick alex.

i am quite shocked at myself that i seem to like “=“. however, this is used in jamoma and maybe other places, which is a bummer.

so i would say, in order: 1) C 2) B 3) H 4) A

with caveat that i might mean ‘B’ at number one slot. all the others are big ‘no’s from me. ‘H’ is this:

<pre><code>

[Alex Harker]

Pete - there's no code here.

[st kr]

hmm, there is in the thread history in my email client. i have gone online to repost here. hopefully it works. <pre><code> ----------begin_max5_patcher---------- 293.3ocqR1saCBCCE95jmhnbMqhvOsvzd.16vT0Dk5skJHAEBcTg5d1GwAzl z.o0ocSrNG633O4LPI7C5dnkytm8DiPFnDBZ4LHSZButnurpnEKiqf20GNwC 7orPuEseoZSqtyTBevFRXh47xiX1wabWTxropqVpp.K1v3IyV6kJ.KdtrlBa 4aR0qOafRqeDihi2DFvhxEtP1VTDtIjs+qVq6ry8VL45srWZ.ea3b1dWlqTp 6H3WhdottFT1ev9iKPa9hvJtEXEYIdXibAQNdlsJrg+AhVeY9vp6wrEIK5lH KL8aqwzc+OqQ717hllyfoUpUH2NpGY9j13j6BPoT4k3eOtANKmqOEcJLiSrc bb6LdV525+7xq0GAipShiE08xWoeBzhp+1H -----------end_max5_patcher----------- </code></pre>

[Francesco Cameli]

My order of preference is:

1) G

2) D

3) C

[Owen Green]

Hmmmmmmm.

B, F, C, E, G, A , D

[Rodrigo Constanzo]

G, C, B

[Alex Harker]

Thanks all.

As we all know, in the world of alternative voting no-one gets what they really want, so the final result is C (or =).

[Pierre Alexandre Tremblay]

Hello

My vote goes for G, because of the factorization geek factor - it feel expansive. A is my second, then the rest is relatively all bad, with a special mention to E as the worse idea ever. I hope this helps.

[Alex Harker]

See next alpha