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

[zestoi]

Funny you should mention it...
I just had a serious little issue with Win7 and have totally switched to Linux (Ubuntu Studio)

I was going to try MM out in Wine, but if a native Linux version could be available... :eek:


Edit
Also, I am happy to test Linux versions out.

I'll shoot you a pm

replied to your PM, cheers. i'll probably see how tricky building on linux will be today then

[zestoi]

quick update... i now have working versions of midimasher for windows, mac osx and linux...

will release them all in the next version once i've improved my launchpad mapping. if anyone wants to try them in the meantime i can release earlier tho...

[zestoi]

quick update... the mac osx and linux versions now support built in midi ports, so no need to use the IAC Driver etc. windows version will have virtual midi ports maybe sometime if i can get access to the loopMIDI api or find some other code.

having builtin virtual ports should reduce latency since now instead of data being processed like this:

MM <--> VirtualPort <--> loopMIDI <--> VirtualPort <--> Traktor

it's just doing this, so bypassing one set of midi layer processing and any extra delay caused by going via a sep app:

MM <--> VirtualPort <--> Traktor

if a V: is put at the start of any midi port name it will first look for a port named like that (minus the V: ) and if doesn't exist will create a virtual midi port

normal and virtual ports can be used together in the same open_midi_device() call

open_midi_device("mydev", "generic", "real in", "V:virtual out")

open_midi_device("traktor", "traktor", "V:Traktor to MM", "V:MM to Traktor")

[raags]

Hey mate... shot you a PM trying to get a MPD16 working with MIDImasher. would love your help

[zestoi]

Hey mate... shot you a PM trying to get a MPD16 working with MIDImasher. would love your help

don't see any new PM atm but sure... there seems to be some quirks with the mpd's and i'd love to work out what it is.

they seem to sort-of-work with the virtual midifighter code for example - but it's like the pads are released before they actually are.

i'm sure we can debug it though... and any fix should then fix any/all mpd i presume/hope

[raags]

Ahhh wtf... No idea where the PM went. I'll write it out again...

Basically I'm trying to get my MPD16 working with Midimasher/MidiLoop in traktor. it's connected via MIDI (NOT USB) through my M-Audio Delta AP, which is identified in Traktor and Midimasher as an in as 'Delta AP MIDI'.

I've tried to get it working by altering the line:
open_midi_device("mpd18", "mpd18", "Akai MPD18", "Delta AP MIDI", 2)

to include Delta AP MIDI... this didn't work.

Then I tried to use learn.exe to program it, selecting '1: Delta AP MIDI' as the device to use. I get the following error:


Where am I going wrong? Any help would be greatly appreciated

[zestoi]

what happens if u have a config with this line in:

open_midi_device("mpd18", "mpd18", "Delta AP MIDI", "Delta AP MIDI")

the first port name will be the most important, as that's the port midimasher will read from and i presume both in+out ports will be the delta.

if u then run debug.bat in theory it should output your pad presses at least. tho since learn.exe died it could be something more serious - would be odd tho...

could u paste me the output from running that? and/or if u run debug_file.bat it should create a debug.txt file with any output in after u ctrl-c unless it crashes and then won't be able to probably... i'll have some time later to look into it

edit: if there's only midi input from the mpd18 (i have no real clue about it) then this would/should work:

open_midi_device("mpd18", "mpd18", "Delta AP MIDI", "")

[raags]

Not sure if it makes any difference but my pad controller is the MPD16 which is marginally different to the MPD18. It's going into the MIDI IN of my M-Audio Delta AP rather than running via USB as there's no Windows 7 drivers for it.

Altered the config as you said and I just tried running debug.bat... It doesn't crash, it responds to key presses from the pads. I couldn't copypaste from the command prompt it created and was too lazy to open a new one so I just took screenshots.


(right click/open in new tab for bigger)

Still learn.exe is crashing when I choose Delta AP MIDI though.

Thanks so much

[zestoi]

Altered the config as you said and I just tried running debug.bat... It doesn't crash, it responds to key presses from the pads. I couldn't copypaste from the command prompt it created and was too lazy to open a new one so I just took screenshots.

awesome pretty much working then... it's complaining about device midifighter1 not being connected so there must be some typo with the naming of those ports in the config verses your virtual midi ports.

the port names are case sensitive (something i keep meaning to change - will do for the next release) so u need to change your virtual ports from like "Midifighter1 Input" to "MidiFighter1 Input" etc and that should do the trick

looks like the notes sent out by the pads match the mpd18's ones so i'll copy the mpd18 config to mpd16 for other people to (hopefully) use.

Still learn.exe is crashing when I choose Delta AP MIDI though.

this sucks... i'll have a look at the learn code later. it does die pretty quickly tho which is odd - shouldn't be any midi sysex or anything coming thru as the RtMidi (for learn.exe) has been configured not to pass it on. odd.

Thanks so much

no problem - always glad to help people try out midimasher - esp when they have a controller that doesn't have a config file yet

[raags]

Hmmm I altered the port names in MidiLoop to "MidiFighter1 Input" etc, closed loopmidi and midimasher, reopened loopmidi then midimasher and it's still giving the same error in debug.bat and midimasher.bat.

"device[midifighter1] is not connected"

ideas?

also just tried renaming them in loopmidi a la 'midifighter1 input' and same issue