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
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
Post new comment