fl.read buffer: instantiation only?

Usage Questions
1

Should I be able to update fl.read~'s buffer on the fly? I do hope so.

If yes, then, should I also expect to work with a multichannel stream? I’m getting badness where it seems to drop the tag:

38
38902×266 50.1 KB

So that fl.pack~ is going into fl.read~, and fl.tomax~ seems to confirm that the vector is properly tagged…

It stops complaining if I untag and then tag again. But I’m not convinced it actually changes buffer. If it should be, I’ll untangle everything and see if I can get it working with a more deterministic test than my current patch.

Also: if this is something I’m meant to be able to do, what’s the least horrid way of getting a bunch of buffer names into fl? frommax~ doesn’t like it at all if I send it a list of symbols (presumably because fl doesn’t allow a vector of strings?), nor receiving a string at all in mode value. So it looks like I need as many frommax~s as I want streams? :sob:

2

Answered most of my own questions, sorry for noise:

  1. Yes, I can change buffers on the fly
  2. Yes, this works with streams
  3. No, there isn’t a cleverer way of getting a bunch of symbols into fl. I think I’d like it if fl.frommax~ =<n> gave me n inlets and produced a stream. (I’d like it even more if I had a unfaffy way of putting a list in and getting that turned into a stream)
1 Like
3

(kind of OT, but it looks like someone’s using FrameLib for their performance next week!..)

4

:sunglasses: (I used it for that bill we shared at electric spring last year too! I’m full of love for it)

1 Like
5

I cannot think a way of doing this without multiple fl.frommax~. In fact, while experimenting with other ways I can’t seem to make untag~ actually untag a frame with a string value.

6

I am aware that some kind of numeric symbol table would be a useful thing, but no-one bugged me for one yet - issues or requests on GitHub are the way to make me do things now :wink:

2 Likes