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
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.
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 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?
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
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?
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
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?
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.
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
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.
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?
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.
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)
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.