[mxb]

edit: This tool has been officially released click here for details and download

Final beta (v0.9) released below

Mods: Please update the title to indicate this is the final beta (version 0.9) thanks!

This post has been edited by mxb: 08 June 2011 - 10:18 PM

[Airjob]

wow, you're quick indeed .

great to see your work is going on, nice code.

I thought in last two days about a more generic / genereal approach for compact "one-fader" - DAW controllers.
E.g. there is the cubase and Cakewalk hardware, too. Or think about e.g. the iPhone iPad - you could easily write a midi controller which simulates
a FaderPort or Frontier Alphatrack

So what do you think:
is there a chance to find a common interface / architecture which

a) covers the common subset: transport, manual and automatic(!) / device track selection ?
B ) can be massively modified for specific device implementation (like e.g. your status line display and specific buttons) ?
c) can maybe be married with Duplex in some way ? E.g. we could take advantage of the controller simulation features

For example right now I guess it was possible to derive a new Class from FaderPort and just override the Midi handler functions
in order to easily create adapters for new devices easily.

This post has been edited by Airjob: 02 November 2010 - 11:57 AM

[mxb]

Airjob, on 02 November 2010 - 11:39 AM, said:

wow, you're quick indeed .

great to see your work is going on, nice code.

Thanks for the kind comments about the code. I have some spare time at the moment.

I'm still learning Lua scripting and I'm not yet too comfortable with the OOP implementation. I still need to have a play around with it to feel confident about working with it.

Airjob, on 02 November 2010 - 11:39 AM, said:

I thought in last two days about a more generic / genereal approach for compact "one-fader" - DAW controllers.
E.g. there is the cubase and Cakewalk hardware, too. Or think about e.g. the iPhone iPad - you could easily write a midi controller which simulates
a FaderPort or Frontier Alphatrack

So what do you think:
is there a chance to find a common interface / architecture which

a) covers the common subset: transport, manual and automatic(!) / device track selection ?
B ) can be massively modified for specific device implementation (like e.g. your status line display and specific buttons) ?
c) can maybe be married with Duplex in some way ? E.g. we could take advantage of the controller simulation features

For example right now I guess it was possible to derive a new Class from FaderPort and just override the Midi handler functions
in order to easily create adapters for new devices easily.

I agreed in that a common approach to controllers would be ideal.

Not having too much knowledge about the OO aspects of Lua or Duplex could something like the following be created:

• 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.

If the above was availble, creating DAW controllers would be a case of just tieing a bunch of the above classes together.

This might be how Duplex works -- I haven't really dug that deep.

[danoise]

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.

[mxb]

[edit: out of date information]

This post has been edited by mxb: 03 November 2010 - 04:52 PM

[Airmann]

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

mxb said:

* 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
http://www.infosun.f...docs/SC2008.pdf

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.

Conclussion:

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.

Quote

* 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

[mxb]

.

This post has been edited by mxb: 15 November 2010 - 06:53 PM

[mxb]

After a lot of code refactoring and 3 rewrites (!) here is the final beta version of AlphaTrack support for Renoise.

Please find it attached to this post along with a PDF command reference document.

I will be giving this a run through its paces over the next two weeks or so to try and identify all the bugs. If anyone else has an AlphaTrack and wishes to assist please do so and report any findings either in this thread or as a private message.

All five editing modes have been implemented. A brief overview of them:

• Mixer mode - allows quick access to controls used in the mixing stage e.g. track volume, panning, track output delay, song groove
  
• Pattern edit mode - allows access to commonly used controls when writing songs e.g. input octave, instrument selection, moving around the pattern editor, hiding/showing columns, setting the pattern length
  
• DSP edit mode - allows the user to change the parameters of any DSPs in a track (using the approach of select parameter / set parameter value)
  
• VSTi edit mode - allows the user to control VST instruments (using the approach of select parameter / set parameter value)
  
• Sample edit mode - allows the user to modify sample based instrument sample settings e.g. loop mode, nna, tuning, autoseek, beat sync

All modes can optionally modify the Renoise window to show the most relevent tab for the current operation.

All modes also have full feedback. The fader will automatically move to where is should be for the currently selected function. All LEDs illuminate to indicate their current roles.

The LCD display screen displays the most useful information relevent to what the user is doing. For example:

• Mixer mode - Position in the song sequence, track name, volume and panning
  
• Pattern edit mode - Pattern number, position in the pattern, input octave and selected instrument name and number
  
• DSP edit mode - Selected parameter and value
  
• VSTi edit mode - Instrument name and number, selected VSTi parameter and value
  
• Sample edit mode - Selected sample and name, loop mode, tuning

Obviously due to the limited 32 character display, not all information can be displayed at the same time. Thus, if the user is changing something that is not on the current modes 'default' display then more relevent information will be displayed instead. This will be replaced by the default information after a user specified 'timeout value'.

To install: Just drag and drop onto the Renoise window as with any other tool
To setup preferences: Tools -> AlphaTrack Support -> Preferences
To connect: Tools -> AlphaTrack Support -> Connect
To disconnect: Tools -> AlphaTrack Support -> Disconnect

Automatically connecting on Renoise startup can be enabled in the preferences dialog but is disabled by default on installation.

I would like to just say a big thank you to the Renoise developers for making customizations such as this possible and easy to implement.

I have also tried to make the code easy to read and seperated it into easy to identify sections (although not object orientated).

If you have the hardware, please download this latest version and assist me to find all the bugs before we progress to the next stage of uploading it to the Renoise Tools page.

Thanks,
Martin

Attached File(s)

•  com.mxb.Alphatrack.0.9.xrnx (24.98K)
  Number of downloads: 55
•  renoise-alphatrack-command-reference-0.9.pdf (259.84K)
  Number of downloads: 80

[Airmann]

Hey Martin,

nice to see new stuff from you. Very exciting features. Sample editor mode is really interesting. I thought about that too, but my focus was more mixing related.
Interesting: it seems that you focused anyway more on song creation than me (pattern mode, vsti mode...), so your driver has a slighly different flavour than mine. But that's a good thing: long live innovation :-D.

Thanks for the hello at IRC - I was away.

BTW:
The guy called "sauli" had a question regarding "automation envelope recording". I think his feature request of loop recording is already covered by
the usual DAW's write, touch, latch modes. These modes are also implemented in my driver, and are also implemented in Reaper - also for the Alphatrack.

Another thing: my impression regarding DAW controllers so far is, that we are doing pioneer stuff here. It seems that almost no Renoise users own DAW controllers like Alphatrack, FaderPort et al. I guess it's the classical "chicken or the egg" problem: without driver it makes not much sense to buy an Alphatrack or FaderPort for Renoise. A common MIDI controller like the Nanokontrol was maybe the better choice before 2.6. Maybe there are some guys out there who come from other DAWs and already own a DAW controller, but so far I've received no real responses from serious users. Guess we need patience here.

CYA ,,,

BTW: I think you have improved your button mapping. Everything looks very cleaned up, now.

This post has been edited by Airmann: 15 November 2010 - 11:41 PM

[Conner_Bw]

Airmann, on 15 November 2010 - 11:32 PM, said:

Another thing: my impression regarding DAW controllers so far is, that we are doing pioneer stuff here. It seems that almost no Renoise users own DAW controllers like Alphatrack, FaderPort et al. In fact it's the classical "chicken or the egg" problem: without driver it makes not much sense to buy an Alphatrack or FaderPort for Renoise. A common MIDI controller like the Nanokontrol was maybe the better choice before 2.6. Maybe there are some guys out there who come from other DAWs and already own a DAW controller, but so far I've received no real responses from serious users. Guess we need patience.

Have you guys considered posting in the PreSonus and Fronteir Design forums?

It's probably easier to get someone who owns the same hardware to give Renoise a try than it is for a Renoiser to buy the hardware to give your scripts a try, know what I mean?

Keep up the good work, the both of you!

[Conner_Bw]

Also try the KVR hardware forum?

A lil' hype doesn't hurt.

[Airmann]

Conner_Bw, on 15 November 2010 - 11:39 PM, said:

Have you guys considered posting in the PreSonus and Fronteir Design forums?

It's probably easier to get someone who owns the same hardware to give Renoise a try than it is for a Renoiser to buy the hardware to give your scripts a try, know what I mean?

Keep up the good work, the both of you!

These are good ideas Conner. I've already planned to contact PreSonus, but wanted to finish some video footage, first.
Also thought about KVR ... we'll see

Good hints and thank you

[Airmann]

ok, did the trick and added my stuff to:

http://forums.preson...5276.page#32984

http://www.kvraudio....ic.php?t=302661

A bit advertising is never bad ;-)

[mxb]

Airmann, on 15 November 2010 - 11:32 PM, said:

Very exciting features. Sample editor mode is really interesting. I thought about that too, but my focus was more mixing related.
Interesting: it seems that you focused anyway more on song creation than me (pattern mode, vsti mode...), so your driver has a slighly different flavour than mine. But that's a good thing: long live innovation :-D.

There is a reason behind all the features -- I sometimes use a netbook! I have been working on this on and off over the last two weeks and trying different features on the device. I hopefully have come up with a good compromise where I use the power of the AlphaTrack fader/led/screen for quick instant feedback but do not try to do 'everything' on the device when using a mouse would be much easier (i.e. cropping samples). I think I am somewhere close to a good balance at the moment.

Airmann, on 15 November 2010 - 11:32 PM, said:

The guy called "sauli" had a question regarding "automation envelope recording". I think his feature request of loop recording is already covered by
the usual DAW's write, touch, latch modes. These modes are also implemented in my driver, and are also implemented in Reaper - also for the Alphatrack.

DSP automation recording is not in this version. I had trouble trying to get it to work, I will look over the code for your tool to see the approach required.

Airmann, on 15 November 2010 - 11:32 PM, said:

Another thing: my impression regarding DAW controllers so far is, that we are doing pioneer stuff here. It seems that almost no Renoise users own DAW controllers like Alphatrack, FaderPort et al. I guess it's the classical "chicken or the egg" problem: without driver it makes not much sense to buy an Alphatrack or FaderPort for Renoise. A common MIDI controller like the Nanokontrol was maybe the better choice before 2.6. Maybe there are some guys out there who come from other DAWs and already own a DAW controller, but so far I've received no real responses from serious users. Guess we need patience here.

Indeed, I don't know what the motivation for yourself was, but mine was definately a case of I already owned the hardware and simple MIDI mapping seemed so limited compared to the integration in other software.

Airmann, on 15 November 2010 - 11:32 PM, said:

BTW: I think you have improved your button mapping. Everything looks very cleaned up, now.

Thanks. I tried.



Also, while on my travels around the Internet I found this PDF document which has an appendix describing the full MIDI specification of Mackie Control Universal (MCU) devices. This is the protocol used by all the larger (usually 8 channel) DAW control surfaces (e.g. MCU Pro, M-Audio ProjectMix and Euphonix MC Control 2). That would make a nice project....

[Airmann]

mxb, on 16 November 2010 - 10:24 AM, said:

DSP automation recording is not in this version. I had trouble trying to get it to work, I will look over the code for your tool to see the approach required.

Will try to refactor my stuff for version 1.01. Just a slight re-ordering of code lines. Maybe this can help you to find the stuff in the 2000 lines.

mxb, on 16 November 2010 - 10:24 AM, said:

Indeed, I don't know what the motivation for yourself was, but mine was definately a case of I already owned the hardware and simple MIDI mapping seemed so limited compared to the integration in other software.

Well, I bought the FaderPort in order to develop the driver. I wanted to have that since a long time. As soon as I realized what the scripting framework was capable of, I went shopping :-).

mxb, on 16 November 2010 - 10:24 AM, said:

Also, while on my travels around the Internet I found this PDF document which has an appendix describing the full MIDI specification of Mackie Control Universal (MCU) devices. This is the protocol used by all the larger (usually 8 channel) DAW control surfaces (e.g. MCU Pro, M-Audio ProjectMix and Euphonix MC Control 2). That would make a nice project....

Oh nice, had a look at those stuff. Were exactly is the protocol defined ? Couldn't find at first look - maybe I'm blind.

best regards

[niNja_pWn3d]

I gotta say here, for a Renoiser not to give this a try would be a pity. Both the FaderPort and the AlphaTrack offer SO MUCH to us from the assistance that Renosie has given us to be able to implement drivers such as this! Both Airrmann and Martin, THANK YOU GUYS! To me personally I think That the FaderPort driver adding some type of (not alot of) editing capabilities would be awesome. Dont get me wrong Airrmann the script you made is AMAZING I dont want to say anything to offend here you put so much work into this project and its evidant. The faderport driver more suits my needs at he moment but the addition of some kind of editing would make it that much more appealing. Anyway BRAVO GUYS!!!!! The preSOnus FaderPort sits to my immediate left and was THE BEST addition to my studio and live preformances I could have made.

_o0m

This post has been edited by niNja_pWn3d: 03 December 2010 - 04:04 AM