Main menu
You are here
Midi automation
16 June, 2009 - 10:42 — nobody (not verified)
Hi again,
what do you think about MIDI automation? Did you see how they solved it in energy-xt? Do you think it's better to add detached automation tracks (like you can see on that picture), or would it make more sense, to add the automation directly to the midi tracks? (Where the volume and the pitch bend is located at the momet?
Cheers, gizzmo
Forums:
Re: Midi automation
The way I'm planning, automation won't be restricted to MIDI tracks. It will apply to almost everything scalar that is already subject to undo/redo commands. That is, for example, track volume/gain, panning, mute/solo states and most wanted of all, to any plug-in parameter.
Each automated scalar subject may be (optionally) assigned to an external MIDI controller and that indeed should complete this recent MIDI controller map implementation.
OTOH, automation deals with editing, storing and rendering pre-recorded values in the time line, probably as a step-wise curve. The curves should be displayed super-imposed to the current track view and control points visually editable as usual.
One of my biggest concerns about automation is how should the automation control points get stored. Should it be serialized inline with the XML session/project file? Should it be stored in separate files, one or several per track? Should it be plain standard MIDI files, for instance?
Well, still wandering :) Any suggestions?
Cheers
Re: Midi automation
...and most wanted of all, to any plug-in parameter.
Yeah, thats right. I am really waiting for it *g*
I think, everything you said goes into a good direction.
Where the data should be stored? Wow. Thats a good question. I do think, that the data could be saved inline the XML project file. Putting it into a seperate file would mean, that you could use the curves in another project like you can import a midi file... and i think you don't need this functionality. In my opinion, an automated value belonds to the song (project) and therefore should be stored there...
Re: Midi automation
Yep, storing automation data points in the session file seems the way to go. I just asked whether it could be a better idea ;)
One other thing is about the observer pattern that has been in the limbo and did not made it through, yet. Remember? It will come back here in glory and it will be fundamental indeed to the automation model as for its original MIDI controller mapping specific purpose. I mean, each variable data subject will get multiple observers alright but also get data history recorded, replayed, edited, saved and/or restored at will.
All that in a nutshell ;)
Cheers
Re: Midi automation
Yeah, your're right. Wow .... someone has to start it ... hm .... but who? and where? ... unfortunately it's a MOST-WANTED feature...
I think one could start to do the data-drawing and data-storing things .... and one could start with the observer/visitor-thing.
Re: Midi automation
Well, the observer stuff already had this sandbox (qtractorMidiControlTest.2.zip), one could start from there...
Seeya
Re: Midi automation
Yeah, I remember. Maybe I should play a little with that. Anyway... I think one could also start with that GUI and file-storing stuff...
Btw: I bought a new PC today. I will now move from an old 1.5GHz Pentium to a new Quadcore. Hope that would speed up qtractor *g* .... And maybe it would also speed up compiling it *g* (But as always, installing this new PC will also cost some weeks *g*)
Midi automation GUI part
Hey Rui,
i started, to implement the GUI for the midi automation. Unfortunately it's really heavy for me to get into the system-architecture... but it's very interesing. Now, I've just started trying to create some additional tracks where the midi controller should end up. As soon as I started, I ran into a problem with this trackList. I created a bug, where the tracklist has no end, so qtractor stops on re-drawing the tracks. Is it possible for you to have a look on my source code? I searched for the failure for a few hours now... maybe you just look at it and say: Here it is?
Regards, mathias
Re:Midi automation GUI part
Is it possible for you to have a look on my source code?
Sure. Where do I look?
Cheers.
Re:Midi automation GUI part
Sorry, for being late...
You can find my sources here. User is "user" and "data99" for downloading.
After compiling you can use the following steps, to create the error:
- Add a midi track
- Select the midi track and add an "Automation Track" with right klick on the first track
- Now a new track, which is linked to the parent track, is gets created. Everything looks fine.
- Now add another automation track to the first midi track
-> qtractor hangs in an endless loop, while painting the track list...
What i did, was creating a new track type "automation" which got a link to the parent track and every midi and audio track gets a link to its automation tracks. All the tracks stay in the one track list.
Now, the problem seems, like i mix something up in the track lists. When qtractor starts to rebuilt the GUI of the tracklist, there's an endless loop in the track list.
I know, that it is poor code, and maybe not even a good starting point. But i WANT to help the qtractor project and i thought to start there would be okay...
regards, gizzmo
Re: Midi automation GUI part
Sorry for the delay, again. I've grabbed the code for review but I must confess I didn't found much time yet to spend at it. But I've already noticed that you're providing brand new tracks for automation data. Not a bad idea but I'd prefer to make automation data a property of usual audio/MIDI tracks; automation data curves would be shown optionally superimposed to the current audio/MIDI track graphical representation and not as a separate track as you seem to suggest. What ya think?
Byee
Re: Midi automation GUI part
Yeah. You're right. I also wondered if it would be better to let the automation draw itself over the track view. But then i thought it would get confusing, if you got more than 1 automation track. So i thought, that tracks direct under the associated midi/audio track would be better to handle. Like you can see here. Then, i thought, that the automation tracks should belong to the audio/midi track so that one can make viewable or not. That's why i did the parent and child thing. But ... actually... i just wanted to get to that state, to see how it would look like, but as you can see, i did not achieve anything... ;-(
Edit: Here's another picture from energyXT and I think I like that alignment. What do you think?
Code review no longer needed
Hi Rui,
let me proudfully tell you, that you don't have to review the code anymore. I found the bug today. What I did was, using the qtractorList item in the wrong way so that I created endless lists of tracks. I solved the problem and will continue playing with the code (just as a sunday programmer, of corse).
Re: Code review no longer needed
Sundays must be easier than wednesdays down there ;)
Play on.
Any progress?
Hi Rui and Gizzmo!
I just compiled the latest svn qtractor as I was hoping there might be some initial support for automation but if any automation code is in then I can't find how to activate or use it. Automation is my #1 most wanted feature for qtractor and I'm sure I remember Rui saying in the release notes for the 'Fussy Doula' this was planned for the next release?
When automation does arrive I'm hoping I'll be able to control the various knobs available for the twiddling under PHASEX, which is starting to get real good now. Does this sound feasable or does phasex lack support for whatever protocol may be required for this to work?
Looking forward to the next release!
Dan
Re: Any progress?
Hi Dan,
I'm afraid there's no big news in the automation front, lately. I also guess next release will overrun the automation deadline once again :( Besides I didn't promised anything, I just said it was popping under the horizon, whatever that means :)
Now seriously, Gizzmo has made some advances on this regard, on its own code base, not in the main svn trunk. However, there's still one infrastructural change to be accomplished on my shift, that meaning the observer pattern and stuff that I've been cooking for way to long now.
Don't worry. It's cooking and stirring, it ain't over-burned (yet, I hope:) nor forgotten ;)
Cheers
Re: Any progress?
Hi Dan,
yeah, and what I've done on the automation front was only a kind of proposal, or let's say a case study. Nothing really usable.
What is phasex? Maybe there's a workaround to use some midi controller messages to control some parameters?
EDIT: Hey ... shame about me. I goggled for phasex and stumbled over a synth i did not know yet? Wow ... i will try that out as soon as possible.
Anyway: As far as i can see, phasex is controlable by MIDI control messages. This means you could record and playback midi controll messages in qtractor inside of a midi clip. This messages could then be sent to phasex and that's a first kind of automation. (Unfortunately you can't draw automation lines, but to record the autiomation values is a good option...)...
EDIT 2: Wow ... now i played a little with phasex. Really cool monster-thing. But again an application, which needs to get midi AND audio input ... (as long it is not a real plugin but a standalone application, this won't be a problem) ....
so far...
gizzmo
Add new comment