Automapping

[METAMATIC]

Hi!

do you think is possible to write a MIOS based application that makes a midibox work like

Novation Remote SL? this controller gets in some way the parameters name and midi ctrl assignment on virtual instruments/plugins, and maps automatically the controller and furthermore displays the knobs names on the display as you see it in your software...i.e. if you enable a softsynth that has 3 parameters called frequency, resonance and pitch it automaps these 3 parameters and shows the names freq,reso etc on the display...very useful i think

for more info check http://www.novationmusic.com/product.asp?id=30&Type=1&bArchive=False

it would be great to have such a feature on a midibox!

bye!

[TK.]

From the MIOS application side this is very easy to realize, it's similar to the Motormix emulation.

But it will be difficult to get those 2x72 LCDs in small quantities - not to say: it's nearly impossible!

In addition, you will have to develop a program which communicates with the MIDIbox, e.g. which handles the parameter names and values. This is not trivial, since nearly each host system requires a special adaption (or a different approach...). Some informations how to handle this are only provided under NDA from the vendors - no chance to get an open source implementation.

Best Regards, Thorsten.

[robin303]

Hi everybody, first of all it's nice to be back after a long absence. It's cool that the midibox forum is still an active community :-)

Anyways, I finally have some time to work on my box again which I completed nearly 1.5 years ago (I'll post some pics of the finished work soon). It has been gathering dust ever since finishing it, just because I never came round finishing the software. The assembly language is just to darn hard if you only have 3 or 4 hours per week. However, I have been watching the porting of midibox apps to C and since this language is more in my alley, it is interesting to play with this.

Back to subject  :D I have read about the Novation Remote SL and its 'automapping' concept sounds pretty good to me! But how would I make my MidiBox 64 'learn' from a host application like Reason or Ableton which parameters are available?

For instance when I activate a ReDrum module in reason, does Reason send out all its parameters over midi? Could the midibox then read this data and thus automap it to any available pots/buttons/leds on my Midibox64?

[audiocommander]

For instance when I activate a ReDrum module in reason, does Reason send out all its parameters over midi?

I don't think so.

That would mean a nasty mess if some application would send data without obvious reason (imagine a setup, and once you switch to some sw-instrument a bunch of midi-signals is sent)... nahh, better the other way round :)

regards,

Michael

[robin303]

It would be that bad if it's Sysex on a specific channel. So how does the automapping feature in Novations Remote SL work then? Preconfigured patches? There must be some kind of "program change" signal coming from Reason for automapping to work, right?

[TK.]

Most host applications support the possibility to include a special driver for a controller today. Best example is Logic/Mackie Control or Korg Micro Kontrol, the drivers have direct access to parameter names and therefore can send it to the external device via MIDI, USB or a similar interface.

Unfortunately the API to the drivers are not standardized, and they are not open like VST or VSTi

Another approach is the way how NI Kore is working - it acts as a host or extender, has direct access to all VST parameters and communicates with the external control device via USB - NIK is also no open interface, no benefit for us

But if you search for a nice programming experience, just try to implement the Micro Kontrol protocol. The spec is available somewhere at the Korg homepage, and you could use midibox_mm as a template

Best Regards, Thorsten,

[rambinator]

how difficult is it to implement something like KORE? it is a really good idea of NI to sell something with hardware to get rid of the piracy-problem. but isn't this thing "just" a vsti-wrapper like energy-XT mapping the vsti-automation to midi? or to it's own protocol?

[stryd_one]

Selling hardware doesn't kill a piracy problem because pirates will just use something else. What, you think that the pirate will suddenly find piles of cash to spend on hardware? ;) 80% of software pirates are poor mf's who can't even afford windows.... People don't pirate cause they want to, they pirate cause it's the only way they can get the software. Yes, there are a few dodgy studios out there, but most of the people who steal the software, would never have had enough money to buy it anyway. It's not the problem the manufacturers make it out to be.

Anyway back to the subject, from what I hear, it's using a korg proprietry protocol over USB, not midi.... But I could be misinformed.

[rambinator]

Selling hardware doesn't kill a piracy problem because pirates will just use something else. What, you think that the pirate will suddenly find piles of cash to spend on hardware? Wink 80% of software pirates are poor mf's who can't even afford windows.... People don't pirate cause they want to, they pirate cause it's the only way they can get the software. Yes, there are a few dodgy studios out there, but most of the people who steal the software, would never have had enough money to buy it anyway. It's not the problem the manufacturers make it out to be.

the truth lies somewhere in the middle. there studies from economists arguing both sides... i did a lot of research on that topic for an essay at university. but what you say is a point for stuff like wave plugins with iLock or similar.

Anyway back to the subject, from what I hear, it's using a korg proprietry protocol over USB, not midi.... But I could be misinformed.

As waht i heard KORE uses something proprietary over USB. I dunno if it is something from korg

[audiocommander]

it is a really good idea of NI to sell something

no ;D

(sorry, couldn't resist)

[stryd_one]

;D

[RTurner]

What about implementing OSC (open sound control) for automapping?  I know that some of the Native Instruments programs support it, Max/Msp, as well as some of the cooler boutique-electronics type controllers (Monome, Lemur).  Not only that, but since OSC could let you embed midi data within it over some other, faster, interface. 

[stryd_one]

Well then one would need to implement the "other, faster interface" first. IIC_Ethernet perhaps?

[tos]

Heh, yesterday I almost made a new tread about OSC. I wrote about i screen of text

and then trashed it.

TK/stryd_one: you should be able to tell us, how hard(in exp. and money units) is to make

a Ethernet module for MBHP?

Osc would be an interesting stuff to play with (ex. Traktor 2 can control other Traktor via OSC)(I'm kinnda Traktor oriented)

Let's say that there is no other way of reading if some pushbutton [that acts as toggle in app]

is down or not [so you could control a led associated with it], this way, you must assume their

initial state and then just toggle leds intuitively, there is some more stuff but this troubles me

@ the moment.

[stryd_one]

It's not impossible but it's not easy at all... Oh and if I remember rightly OSC runs over UDP so you'd have to write a TCP/IP interface too.

Much of the work is already done in publicly available source code, but even strapping it all together is a big job. You could look at something like the Microchip ENC28J60 or similar... an IIC - Ethernet+TCP/IP+OSC module would be doable... But what for? Is there any practical use that MIDI couldn't cover off?

[stryd_one]

Just looking into OSC, looks like it's focussed on 32 bit data, so is it worthwhile to implement on an 8bit MCU?

[johnh]

It's not impossible but it's not easy at all... Oh and if I remember rightly OSC runs over UDP so you'd have to write a TCP/IP interface too.

Could you clarify?  If OSC uses UDP why do you need TCP?  Or is there another application that requires TCP that I missed in the discussion?  UDP runs over IP.

[audiocommander]

But what for? Is there any practical use that MIDI couldn't cover off?

yes, I wonder, too: what's the thing about the host application to tell the MB it's config while most applications support taking the config from the MB anyway...

IMHO all mentioned host applications support midi assignments, so why sit for hundreds of hours and write an MBHP_TCP/IP module and then you still need to implement the receiving handlers in your MIOS-app... I can imagine this consumes valueable space and processing time?

I mean, this would be definitely a nice module to play around with, but the reason for this is not really clear to me :)

Best regards,

Michael

btw: there's a nice software called iMIDI from GrantedSoftware for Mac OS X, that provides a MIDI connection over ethernet if installed on every client (just to mention it)

[Rowan]

btw: there's a nice software called iMIDI from GrantedSoftware for Mac OS X, that provides a MIDI connection over ethernet if installed on every client (just to mention it)

We really are spoilt for choice when it comes to MIDI over ethernet on OSX, I prefer the built-in MIDI networking in the Audio-MIDI Setup App on Tiger. Bonjour make this stuff so, so easy  ;D

I really want to try the Audio over ethernet AU, just haven't had a chance.

[audiocommander]

I prefer the built-in MIDI networking in the Audio-MIDI Setup App on Tiger

cool,  8)

how could I've missed that? I always thought that came with iMIDI :)

[Rowan]

cool, 

Too right, Tiger has soooooooo many little built in features like this that make it without a doubt the best OS for Audio/MIDI.

I love Aggregate devices to.........The TDM bridge in Logic.........The fact you can chose the picture for devices in AMS.........Distributed Audio Processing...........I could go on for hours.

[stryd_one]

Here's a thought for you though, a $50 Pentium 2 with a gameport midi interface running linux/PD can happily do the conversion from MIDI to OSC...And some other funky processing on the way :)