storage / playback of osc streams

[ramagottfried]

I've just learned o.table is going away in favor of something more powerful.

For me the most important features to include would be: 1) storage/recall of bundles 2) read/write storage to disk 3) sorting/lookup by field (e.g. sound description data, tag, etc.)

• ideally also with lookup rules (e.g. closest match, closest match that is less than query).

Two use cases I can think of off the top of my head for the lookup/sorting would be for concatenative synthesis, and lookup of time tag for playback/sequencing.

[adrianfreed]

To clarify:

o.table is not part of the first release or the kernel of "o." It can be found in the unsupported folder we are currently calling "experimental".

At this stage there is no funding or staffing for further development work on it and similarly no plan in place on how to maintain it. I hope this situation will be different in the fall but you may have to use dictionaries or a different tool than Max to solve the problem of persistant storage of parameters. I am curious to learn what the IRCAM team are doing for this.

On Jun 26, 2014, at 3:07 AM, ramagottfried notifications@github.com wrote:

I've just learned o.table is going away in favor of something more powerful.

For me the most important features to include would be: 1) storage/recall of bundles 2) read/write storage to disk 3) sorting/lookup by field (e.g. sound description data, tag, etc.)

• ideally also with lookup rules (e.g. closest match, closest match that is less than query).

Two use cases I can think of off the top of my head for the lookup/sorting would be for concatenative synthesis, and lookup of time tag for playback/sequencing.

— Reply to this email directly or view it on GitHub.

[ramagottfried]

I spoke with Jean Bresson for while today about it, and as far as I can tell there's not much going on at IRCAM to solve this problem. So far o.table is by far the most efficient way to deal with recording OSC streams (I successfully recorded and played back a 500MB OSC file today with acceptable results).

I could imagine that if o.collect could handle a 500MB bundle, that o.table would be unnecessary, so maybe this is a possible solution -- provided that there will be a way to store a bundle with a patch via o.message (or some other way if o.message is going away).

[adrianfreed]

what happened to gdif?

[adrianfreed]

Large bundle handling is a good goal for all our objects so should be part of the review of libo's storage architecture. We would probably have to abandon using the stack. memory mapped files have been discussed too. This would be good to bring up with David to see if it a useful Terraswarm related activity.

[adrianfreed]

Persistant storage of this sort with perhaps Terraswarm GDP is a worthy goal but won't be in place in time for our immediate needs. Let's continue this work as experimental .