Routing objects review

[Alex Harker]

Please take a look at the list of routing objects and provide answers/thoughts on the following questions:

Note that routing refers to routing whole frames/frame stream manipulation, as things like splitting etc. come under the vector objects.

1. Are there any objects missing here?

2. Are there any object features missing here?

3. Any issues with info documentation, either general, or specific to a given object?

4. Any changes to parameter names/entry desired here?

5. Any issues with object names?

[Alex Harker]

Issue #37 was marked as a duplicate of this issue.

[st kr]

fair enough. here is my post on this issue repeated for clarity:

hi. since the wonderful alpha 0.8 and explicit control over multistreams, i immediately find myself needing some sort of [fl.slice~] object. for example i take an [fl.source~ ~9 44100 100] and process the 9 input frames together in some way. then, i need to split them into 3 sections each to process each group individually in some other way. it is getting very powerful if i have this. i looked at chop/join/sort/subframe/split/unpack but these do not do this. is there a way? or is my feature request a good one? pete.

[Alex Harker]

I'm open to it, but give me a common or dynamic use case that makes it worth writing another multichannel object, rather than just using [fl.unpack~ 9] followed by several [fl.pack~ 3]s.

[st kr]

cool. because if i had an fl.slice~ the slice point could be dynamic. if i use unpack~ and pack~ i am stuck with a fixed slice point. i imagine sending different frame streams to different processors dynamically without ever needing to change the patch. and in only one object.

[Alex Harker]

Actually stream counts cannot be dynamic - they must be known ahead of time. In terms of routing you now have available fl.select~ fl.pack~ and fl.unpack~, and I think you could build what you want with that (given that you can't dynamically change stream counts). I'm not hearing a clear actual use case that justifies a new object yet - this sounds more like hypothesising - convince me I'm wrong.

[Alex Harker]

I'm starting to think that objects that manipulate channels/streams need to have a name that reflects this (should it be streams or channels?). Also unpack/pack are a bit max-centric - someone suggested something else in an email but I can't find it now. thoughts?

[Francesco Cameli]

I think it should be streams, and the multichannel processes should be referred as multistream ones. I think that FrameLib needs to have its own nomenclature to refer to its features, and, to me, "stream" means more than "channel", in this context. What do you mean with max-centric? Do you mean their name of their features?

[Alex Harker]

I mean the names - I think streams is probably better for a number of reasons (they don't have to represent channels/they aren't necessarily synchronous).

So you would vote for fl.channel~ being fl.stream~ or fl.streamnumber? Then it would be something like fl.streampack~ or fl.streamunpack~ or fl.streambundle~ and fl.streamunbundle~ or fl.streamsplit~ or something like that?

[Alex Harker]

fl.streamseparate~?

[Francesco Cameli]

I would vote for fl.stream~. For the other names, I would keep fl.pack~ and fl.unpack~ as they are. I would just specify that they pack and unpack streams and multistreams in the help/info. I think that the name of the objects, generally, should be as concise as possible, while the help, info and parameter names should be more explanatory.

[st kr]

it was you and me discussing the pack/unpack names on the phone. i think we came up with bundle and unbundle then, which i continue to prefer.

DEF fl.streamnumber~ please - i got really confused by fl.channel~.

yes streams is better as channels suggest pure multichannel system.

streamseparate~ is a horrible mouthful :-)

[Owen Green]

I think I was going to suggest something similar to Pete, albeit without the dynamism. My maxcentric use case comes from thinking that if I can pack some things, I should also be able to pull them out by index, like with lists and dicts. So, in the live granualator that I'm using as one way of kicking the tyres of FL, I spit a bunch of signal parameter inputs in to a single fl.source because, huzzah, this signigicantly cuts down on trigger patchchords. I then unpack these straight away but would love it if I could unpack in a way that gets rid of some more patch chords / reduces tangles. Because different streams in this bundle get used in a bunch of different calculations, having something like [fl.<something>~ 2 3] would simplify my code. Hell, if I could name the streams too, that'd be peachy.

fl.sieve? Except I had to google how to spell sieve, so maybe that's a problem ;-)

[Owen Green]

Is #3 (fl.select~ but per-sample) a routing thing, or something else?

[Alex Harker]

A - a patch is worth a thousand words - whilst I understand all your words individually I can't group them into concepts in my head - could you show me your nasty patch and tell me how you'd like it to be nicer?

B - No - you aren't routing whole frames - that is probably a vector thing...

C - I'm making fl.route~ at the moment (is like gate in max) - there could also be a kinda matrix thing will multi-ins and outs, although it'd only be one input to one output at a time. Interest in that?

[Alex Harker]

Are people asking for some combo of fl.unpack~, fl.select~ and possibly fl.pack~ together? Some diagrams would defo help.

[Owen Green]

The patch isn't that nasty as these things go, but if you look in the 'readpositions' patcher, you'll see that it could be more readble. If I could have a single inlet, and then just pull out the streams I need from the bundle for each simple calculation, then it should be possible to eliminate the tangles.

[Alex Harker]

see next alpha