"Intermediary midi mapping" software *discussion thread* (Traktor mapping is a pain)

[cantaloop]

hi there!

i tried to install midimasher but it said it cant find mm.exe !

do u have any suggestion?

running windows 7 on Macbook...

[cantaloop]

hi there!

i tried to install midimasher but it said it cant find mm.exe !

do u have any suggestion?

running windows 7 on Macbook...

okay i got it...i forgot to extrakt...

[zestoi]

okay i got it...i forgot to extrakt...

ah cool

[tdmusic]

This looks pretty amazing. I've had the same idea before, the closest I got was writing a C++ application a few years ago which converted Traktor's OSC output to MIDI (as Traktor 2 and 3 used to only output OSC for control values if I remember correctly, no MIDI feedback), and did some special mapping for the BCR2000 (e.g. storing effect parameters in arrays so it would recall the correct effect parameteers)... started out as Python, which was too slow (although I didn't know a lot about performance optimization back then so I'm sure I could improve that) and then ported to Java for the Mac, but stopped needing it when Traktor Pro came out so that was as far as I got!

Any plans to port to the Mac, or to release the source, in which case I'd love to try and get it up and running?

[zestoi]

This looks pretty amazing.

cheers

I've had the same idea before, the closest I got was writing a C++ application a few years ago which converted Traktor's OSC output to MIDI (as Traktor 2 and 3 used to only output OSC for control values if I remember correctly, no MIDI feedback), and did some special mapping for the BCR2000 (e.g. storing effect parameters in arrays so it would recall the correct effect parameteers)... started out as Python, which was too slow (although I didn't know a lot about performance optimization back then so I'm sure I could improve that) and then ported to Java for the Mac, but stopped needing it when Traktor Pro came out so that was as far as I got!

sounds very cool. tbh my code is more C than C++, tho it's all class based. i haven't coded in C++ in anger for maybe 20 years so am a bit rusty.

i guess python would be too slow. you found java was fast enough? i find LUA pretty quick, tho still could be better, when fractions of milliseconds matter. current unreleased version is quite a bit better i think as i had a main event loop which slept for 1ms if there were no incoming events to process and functions like the slicer had to have embedded sleeps in to send out multiple commands to traktor and have them all recognised. code is almost finished that lets any function queue up messages to be send out a certain time in the future which prevents all the midi not being processed during that time.

could also be used to trigger a set of samples for a drum riff or arpeggio ofc i also fancy having a built in sequencer so i can use sample decks in traktor like a mini ableton.

it's just single threaded atm (apart from the use of RtMidi which is threaded to listen to multiple midi ports) which seems the best way when using LUA.

RtMidi seems to work nicely with multithreaded apps - but even with more mutex locks than i can remember i still for some odd reason had issues with the LUA.

Any plans to port to the Mac, or to release the source, in which case I'd love to try and get it up and running?

i'm hoping to get a mac in the not too distant future - so if i do then i'll certainly maintain a windows and osx version. i don't have any plans atm i'm afraid to release the core code itself - but i might change my mind on that. i wanted to retain some kind of control over it - tho maybe at some point going open source would make sense, not really sure.

[zestoi]

Just a question, will this program be windows only or will it support other operating systems?

windows only for now tho should build fine on linux. i haven't tried in a while as i only really use windows for music/dj stuff.

osx if i get a mac (which hopefully is likely) or i might try to build/test in a virtual osx session - just don't have any spare time atm. there's no technical reason why it shouldn't build on any platform. i chose the RtMidi lib for that reason - and LUA builds on just about anything.

some beta code i've been working on for HID support should be fine too - as uses hidapi which says it works on linux/win/osx

i guess those are the big 3 u are referring to? or some curve ball like BeOS?

edit: pretty sure i just replied to a bot looking at those image urls - but it was a sensible question anyway

[bascurtiz]

Hey Zestoi,

I hope this *bump* will make u consider to do a new version, whereas the LPD8 will function properly

I've tried out an earlier version, and in that, I don't get the suddenly shut-down of Midimasher after loading the LPD8-config, so yeah, I guess indeed, there's a bug when it comes down to the LPD8.

[zestoi]

Hey Zestoi,

I hope this *bump* will make u consider to do a new version, whereas the LPD8 will function properly

I've tried out an earlier version, and in that, I don't get the suddenly shut-down of Midimasher after loading the LPD8-config, so yeah, I guess indeed, there's a bug when it comes down to the LPD8.

cool, will do. i'll do my best to look at fixing that this week. it's bound to just be some minor-ish lua issue. if this kind of thing happens the best way to debug is to open a cmd window and then run mm.exe -i directly instead of clicking on the .bat file. it'll still die - but it'll also output the error.

it's about time i finished testing the version i was working on before new year too which has some performance improvements in. also about time i got my lpd8 out again anyway

[bascurtiz]

Hey mate,
How's the new version working out 4 ya?

[JoeM]

cheers



sounds very cool. tbh my code is more C than C++, tho it's all class based. i haven't coded in C++ in anger for maybe 20 years so am a bit rusty.

i guess python would be too slow. you found java was fast enough? i find LUA pretty quick, tho still could be better, when fractions of milliseconds matter. current unreleased version is quite a bit better i think as i had a main event loop which slept for 1ms if there were no incoming events to process and functions like the slicer had to have embedded sleeps in to send out multiple commands to traktor and have them all recognised. code is almost finished that lets any function queue up messages to be send out a certain time in the future which prevents all the midi not being processed during that time.

could also be used to trigger a set of samples for a drum riff or arpeggio ofc i also fancy having a built in sequencer so i can use sample decks in traktor like a mini ableton.

it's just single threaded atm (apart from the use of RtMidi which is threaded to listen to multiple midi ports) which seems the best way when using LUA.

RtMidi seems to work nicely with multithreaded apps - but even with more mutex locks than i can remember i still for some odd reason had issues with the LUA.



i'm hoping to get a mac in the not too distant future - so if i do then i'll certainly maintain a windows and osx version. i don't have any plans atm i'm afraid to release the core code itself - but i might change my mind on that. i wanted to retain some kind of control over it - tho maybe at some point going open source would make sense, not really sure.

Some constructive feedback, I'm a "professional" lua dev and I've written MIDI apps in C# and a few FOSS MIDI drivers for OS X.

First, at this point most any scripting language will be fast enough. My major project right now uses OO Javascript (Mootools) with lots of inheritance running inside of a Max patch. I'm able to "crab scratch" effects on my padKontrol faster than the Traktor UI can update the LEDs. The JS engine in Max 5 isn't even the best, though I hear they're using the newer stuff in Max 6. My point is, anything will probably be fast enough. I'm using a 4 year old computer and through a USB hub (adds a few ms of delay, did I mention I've written USB drivers before too). You're biggest flaw is probably your runloop. You should try to find a way to use an even queue with no polling and async events. Try googling for realtime runloops, as most of the types you'll find are usually game oriented with UI runloops synced to FPS.

Secondly, if you're not in love with LUA, I'd recommend running away while you still can. I have to use it for my job, but it's a horrible language really. There's not enough cross platform frameworks and the OO frameworks always seems hacky to me. Since a lot of controllers share similiar concepts (pots, pads, grids, faders, leds) it's just easier to use a scripting language with better OO support.

Also for your host app, you might want to look into C# over C++ if you plan to support OS X. The addition of interfaces and the fact that you can run the same binaries (if you're careful to split OS specific functions in a sane way) using Mono and .Net on Windows make help in the long run. MonoMacs C# support for the CoreMIDI/Audio apis is very thorough (I help port those as well ) and you'll get all sort of bonus in async thread handling that can be a nightmare to do cross platform. My current app for my employer is a cross platform realtime audio app and we've had a lot of success plugging in different audio modules for CoreAudio, Windows sound, alsa and port audio on linux. Interfaces really save the day with cross platform.

Then again, you could also do what I'm doing and use Max since it already handels MIDI in realtime across platform, and you can distribute the compiled patches for free. The lua interprator libs are really basic and compile without hassle on all platforms and you could probably easily write a Max C/Java interface to pass midi along, if someone hasn't already written this.

Just some thoughts, hope it helps.