danoise, on 02 November 2010 - 02:11 PM, said:
That was quick indeed. AlphaTrack owners rejoice!
About the Duplex implementation, I honestly don't think it's that important now, now that a dedicated tool is available. This kind of controller is very compact and specialized tool, and would always benefit from a closer integration - Airmanns sophisticated tool is a good example of this.
Somewhere down the road we might be able to have such a complete integration, but I don't think this is important for the Alphatrack owners out there? In the short term, I think it's much more beneficial to establish a common set of features between the Alphatrack & Faderport like you point out.
I think you're right that these type of controllers need "special treatment". And the "uber-generic" solution is probably not the right way.
Nonetheless, I like your Duplex mapping approach pretty much. I guess also for FaderPort or Alphatrack users would like to re-define keys after
personal taste and so on. So a mapping or "minimal" mapping would be nice. I'll think about a common approach, here.
So I agree: a common set of features, or a kind of minimal interface would be nice
* Button class
* LED class
* Illuminated button (inherits from Button and LED)
* Fader class
* Motorised fader class (inherits from Fader)
* Display class
* Encoder class
* PushEncoder class (inherits from Encoder and Button)
* Transport class (<<, >>, STOP, PLAY, REC, REC LED) inherits from multiple IlluminatedButton classes
* TouchScroll (inherits from PushEncoder?)
* etc. etc.
that's a good list which covers pretty nice the "real" hardware. In addition I suggest before building an abstract class hierarchy to have a look at the other DAW controllers on the market (Cubase, Cakewalk). Moreover, I would recommend to not only focus on classes, but also to analyze / design the "big picture"
and to think primarily in "features" or "building blocks" = conglomerats of mechanisms, functions, algorithms. A feature can be encapsulated by a function, a class, but also by many classes or a library etc.. See also http://en.wikipedia....ted_Programming
(excerpt: ...A software product line (SPL) is a family of programs where each program is defined by a unique composition of features, and no two programs have the same combination...). And see
Such a feature woulde be for example the "track / device auto select feature" of the FaderPort driver. IMHO this is an essential feature
for all DAW controllers which provide "motor faders" or "endless encoders". Means: which support controller "feedback".
I guess this feature could for example be packed into a class, be made more abstract and re-used for other controllers. Advantages:
1. re-use saves time, because this is time consuming to implement (at least was for me)
2. stability - this feature is error prone and needs a solid base / proper testing (user acceptance)
Or e.g. the automation envelope reading/writing feature, and so on.
For my next version I intend to refactor my code a bit according to this "feature" approach.
My overall suggestion is to look at the usual DAW controllers and to create a common "big picture" / feature set, first.
Let's analyze and design the big picture, first. Afterwards we can try to adapt our tools to common feature sets,
without sacrifizing the "specialities" of each driver.
A final goal could be to create a google-code project with a "DAW Controller" library of common feature sets / building blocks.
* Encoder 3 will set the song groove amount
Just a thought: why do you bind groove amount to Alphatrack at all, do you alter it that often ? I ask this, because I usually never
touch this parameter during a song project more than once or twice.
Otherwise: cool progress, the status display of Alphatrack is really nice. (which FaderPort had it)
This post has been edited by Airmann: 03 November 2010 - 12:30 AM