recording automation data

[tatch]

Automation is one of the things that I think needs a lot of work in modular LAU. I know there have been discussions about it like this and this. Unfortunately male has been absent lately, and much of modular LAU relies on non* (at least it does to me), but I am impatient and to my knowledge recording manipulated automation data has yet to be discussed.

Current modular performance tools in LAU -- I can currently think of carla, qmidiarp, non*, din, hydrogen, seq24 (but I am tired of seq24) -- can be manipulated in useful ways but none of that manipulation can necessarily be captured on a timeline (other than as audio obviously). A particularly useful aspect of monolithic daws is the ability to record automation data as parameters are being manipulated, which allows performances to be recorded and later modified with greater flexibility than if just audio were recorded. I think this can be accomplished in Ardour (play/write/touch)/QTractor as well since they are a monolothic, but I'm wondering if I am the only person who wishes the same thing could be accomplished in modular LAU? If not it'd be great to get some input from devs and others.

[rncbc]

recording automation is one thing that ardour and qtractor *do* by design. both are timeline sequencers and hosts.

although i like to think of qtractor as kind of an hybrid, but still, both ardour and qtractor (and muse, etc.) are as monoliths as any other plugin host can be.

to let there be here stated, this whole plugin craze (once started by steinberg's cubase and VST in the late 90s for the whole truth there is, nevertheless), it has become the catch-22 of linux-audio ever since.

you just can't think of a modular world (linux-)view if everyone is thinking on plugins-as-modules-on-his/shes-favorite-host and what not. no matter if it's ardour, qtractor, muse, lmms, carla, whatever. plugins just don't marry with modular. only if you are the boss ie. the host.

as a rule, no plugin spec nor host support it will ever help you on that so called "modular world view".

you'll have to ask for a common interface and definite semantics (MIDI is one case; OSC is not yet, but might, would, should, ...)

nuff said.

think about it.

byee.

[ssj71]

I think the best way this could start happening would be for JACK to implement CV ports. They're really just audio ports that are handled separately. A host could simply not have a CV port if it doesn't want to use CVs. Non timeline would probably implement "CV tracks" to record your automation in. Once JACK does it I think more hosts would implement LV2 CV ports too. And then more plugins would have them. This is a little heavier than an OSC implementation since OSC is message based (send an value when you need to) rather than sample based (44100 frames/sec), but its quite feasable without large changes to anything existing. OSC ports would require more infrastructure change. One drawback could be scalability. I understand JACK doesn't do well with hundreds of clients, and you might approach that using CVs.

I've heard jack CV ports mentioned a few times but never any official word. Maybe the concept doesn't really fit in with the JACK devs roadmap. IDK.

[rncbc]

you just can't think of a modular world (linux-)view if everyone is thinking on plugins-as-modules-on-his/shes-favorite-host and what not. no matter if it's ardour, qtractor, muse, lmms, carla, whatever. plugins just don't marry with modular. only if you are the boss ie. the host.

as a rule, no plugin spec nor host support it will ever help you on that so called "modular world view".

I heavily disagree here.
Plugins work nicely in a modular setup if the host is smart enough about it.

you'll have to ask for a common interface and definite semantics (MIDI is one case; OSC is not yet, but might, would, should, ...)

We already have all the semantics needed - plugin parameters.
It's the host job to map parameters to OSC, MIDI, or whatever comes next.

in a "plugin ideology", the host, every host, will tend ultimately to be a do-it-all monolith no matter which color you'll paint it

in the "ideal" modular world, you talk about control and data (signal) interfaces, between stand-alone applications--every JACK client application stands as the model of this "modular ideology", however, as the OP asked, the common "language" on how we do control automation recording/and playback recall is not universally defined: MIDI has a well rather limited semantic for this purpose; OSC lacks the "do this and what" semantics. and what i mean about "semantics" is what message or event maps to what function and when, something that has to be defined by a letter of law--iow. a definite protocol or an API standard of some sort, hopefully open, or else closely negotiated between the intervening peers.

the interface closure that just occurs between a host and a plugin is not what is mean about a modular system. for all purposes the host, with or without its components, plugins or not, is or becomes a module of its own, when posed in a modular environment. please, don't confuse things. i believe the OP meant about automation across the modules as in a modular system, not of the closed autistic world that is a host and its inner pieces talking their dialect (ie. plugins).

hth.
cheers

[ssj71]

NSM is driving things for the better, but male seems to not want to get online now...
There was supposed to be a way to communicate Non-Timeline and Carla (like it does with Non-Mixer) but I need male to explain its API.

It looks like its all handled by OSC. I think he originally did it by numbering everything, then later realized it should just be by name. Look at ln 686 of Mixer.C of the non source to see how it talks by number. It looks like you and timeline need to exchange a "hello" message (handled in ln 120) to initialize then after than you are sent messages addressed to each mixer strip (see ln 604). The mixer then forwards the messages to the strip. I think this is just for legacy compatibility. Each element in the mixer strip (fader, peak meter, plugins etc) are all modules and most of the handling is there. Look at Module.C ln 375 and the following functions (https://github.com/original-male/non/bl ... ule.C#L375) I think he's using liblo and just assigning a callback for the path of "/strip/STRIPNAME/MODULENAME/CONTROLNAME" and if its "CV" then it just is in range 0 to 1 otherwise it has an extra "/unscaled" added to the end of the path and it should give an exact value to set the port to.

To register a port to timeline for carla you could probably just take the endpoint object in nonlib/OSC/Endpoint.* and use the add signal call on each parameter https://github.com/original-male/non/bl ... int.C#L962 or write your own equivalent that sends a message "/signal/created sssfff PATH, IN/OUT, min, max, default." Each time a plugin (or any mixer module) is added he does this for each port.

Does that help at all? I'm oversimplifying things. I haven't figured out how mixer and timeline know which OSC port the other is on. I guess NSM probably sends them each a message giving the other's port. This page is what got me started on the trail: http://non.tuxfamily.org/wiki/UsingMidiWithNon (see also http://non-mixer.tuxfamily.org/MANUAL.h ... .1.2.3.1.1.) I guess I'll put adding this functionality to carla on my todo list. Too much to do so little time.

I think it would be nice to have everything automatic, but being able to just manually enter in the osc path for a parameter would be a great start (the osc analog to midi learn).

[ssj71]

I edited that response above while you were responding to me. I can try and play with it, but it will probably be a while. Let me know where you get stuck, I kinda like reverse engineering others' code. I'll see if I can figure it out.

[ssj71]

I just poked at it a bit, but you have to be a "known peer" for timeline to add a signal to timeline.
More poking: sending

Code: Select all

oscsend localhost 57125 "/non/hello" "ssss" "osc.udp://localhost:57120" "carla" "2.0.99" "cow" 

lets me register as a new peer, but it still won't let me add a signal. I'm not sure what port lo_send_message sends FROM.

AHA! sending the non/hello makes timeline respond with /signal/list. I guess I'll have to trace down the whole exchange.

[ssj71]

WOOT!

Just looking at your code and non. I notice you just send the /pluginName/ as the 3rd level of the path, but non expects it to be /pluginName.instance/ maybe thats a factor. Also (obviously) the path must be unique or else it will say it already has that path and ignore it when you list it (see https://github.com/original-male/non/bl ... int.C#L907).

Ah... Are the ones that work bounded from 0 to 1? It looks like (here https://github.com/original-male/non/bl ... nce.C#L664) that it may only currently be implemented for CV ports (limited between 0 to 1). I notice the ports you have in the screenshot are enumerations or toggle type ports. I'm guessing it could be related.
Anyhow, trying to help.

[male]

Progress!

scr031.png

For some reason not all parameters appear in the list.
It's not random, so there is a rule somewhere in non code for discarding some controls.

I think you've just about figured the interface out. I had planned to clean up, factor out, and actually document it (and even package it as a separate library perhaps). But between libmapper and rtosc... I don't want to contribute to the proliferation of a bunch of incompatible OSC signaling schemes. I had hoped to find some way to get it all working together, but obviously don't have time for it.

Are you doing your implementation of the protocol from scratch or reusing the OSC/Signal code from nonlib?

[tatch]

great job falktx and ssj71! Totally awesome. non-timeline still needs to be able to record automation but this is a tremendous step forward!

I had hoped to find some way to get it all working together, but obviously don't have time for it.

I agree that this is something that should be more formally defined. But given your circumstances, at least for now I think it would be great if it could be brought to basic usability, we oughtn't wait forever.

[ssj71]

great job falktx and ssj71!

Falk really did all the work. I just tried to help a little by snooping around through the code. Thank him.

Male! Its great to hear from you after long silence. We've missed you.

If that's the case why even bother having a min and max value?

from the "for now" comment in the code, I think it just wasn't implemented before he got too busy. Or perhaps the min and max actually allows the timeline to show the bounds even though its actually passing 0-1. But I guess he'll answer for himself.