Add new comment

Hey... here I am again, with some small questions. (I hope that's ok, but after some small hacks did work I want to do it in the right way, and ... at the moment I got some time left....)

Now here's what I think we need for the controller-mapping: I think the user should be able to create a list of midi controllers and be able to connect it to different functions. Maybe something like the guys from Hydrogen did with their midi controller mapping.

So, as I see, the midi control events are registered in qtractorMainForm constructor whith method setNotifyCtlType. I think, when the midi ctl event comes in, one should be able to know from which midi bus the information came as the user wants only to connect special midi inputs, or maybe only using the dedicated controller input. What do you think about it?

The second thing is the MVC pattern, you mentioned. Am I right, that the model data is for example inside the properties of a Track (in this case the GAIN property?. So ... the property is changed with the TrackGainCommand (this is what the user will be able to select in Midi-Controller-Map), and therefore, the control data can not be sent back when the model data changes, as this might end up with a delayed loop?

What I think, is that another model (i.e. MidiControlMap) has to be added, with its own data. The midi controller is able to change the MidiControlMap-Data and is notified when data changes. In the other direction, when ModelData changes, the MidiControlMap-Data is updated and generates the midi control data? What do you think about it?

As a last step, I think, there should be a possibility to store the control data somewhere. Maybe this could be on a dedicated bus (in addition to a audio and midi bus). This control data could than be mapped to anything else ... ?!? ...

Ok ... I'm sure, that i mixed up a lot of things here ... but maybe a small discussion will help me to do things better ;-)