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

[zestoi]

works a charm now!

have a DIY midifighter clone here.

but want to define my own mapping, including slicer-like functions.

how can i access the midi-clock from traktor in MM?

cool! so you're using it via hid mode in midimasher or as a midi device and using something else to convert to midi? curious as i'm keen for any feedback on the hid stuff. i'm also adding in the ability to send data to a hid device but that's not needed for a gamepad type thing ofc.

what config are u loading atm? mappings can be completely customised and aren't too tricky once u get your head round them. they're just based around writing snippets of code that deal with what happens when a message comes in that u are interested in.

the file config/launchpad.lua is the most complete mapping atm, but is also quite complex so a bit confusing... i need to add more documentation to the webpage sometime.

i'm up for answering any question on using lua in midimasher anyway

you can't access midi clock atm. it's being decoded and used by the internal sequencer i've been working on but will need to make it available anyway now for the slicer stuff.

what data do u want to get from the clock? i presume not all the 24 ticks per beat... being able to capture() and do stuff on the beat via the midi clock is what i need and also wouldn't hurt to be able to get hold of the actual bpm in a variable for other use. so i can do something on each beat based on it.

[muffintop]

I don't get it...
Here are screenshots of my problem...
Also, to run MM i have to double click on the midimasher.sh and run it in terminal.
Double clicking on mm does nada.


---EDIT---
WORKS!!!!

thanks zestoi, you're the man

[zestoi]

I don't get it...
Here are screenshots of my problem...
Also, to run MM i have to double click on the midimasher.sh and run it in terminal.
Double clicking on mm does nada.

can you post a bigger screenshot - i can't make out much from that really. if u dble click it will run. you can check by something like "ps -efa | grep mm" which should show up the process. if you want to be able to select some option then you need to right click and "run in terminal" tho personally i do everything via a shell anyway, so i do:

$ cd src/midimasher/
$ ./midimasher.sh 
midimasher: build 20120326 (Linux)

#1: launchpad.lua
#2: debug.lua
#3: default.lua
#4: mpd18_midifighter_4banks.lua
#5: lpd8_midifighter_4banks.lua
#6: lpd8.lua
#7: mpd32_midifighter_4banks.lua
#8: gamepad_midifighter_4banks.lua
#9: launchpad_scroll_demo.lua
#10: midifighter_4banks.lua
#11: launchpad_twitch.lua

select a config >

tho u can also just run "./mm -i" as that's all the midimasher.sh script is doing. the shell script is more useful tho if you run something like the launchpad.sh one which preselects the launchpad config and so then can just run in the background, no need for the shell. launchpad.sh is just this:

#!/usr/bin/env bash
./mm -f launchpad.lua

but you could just run "./mm -f launchpad.lua &" from a prompt instead if u wanted

i'll debug your actual issue tho if u can post a bigger photo or just cut&paste any output.

[zestoi]

---EDIT---
WORKS!!!!

thanks zestoi, you're the man

awesome what did i fix in the most recent version?

[derschaich]

cool! so you're using it via hid mode in midimasher or as a midi device and using something else to convert to midi? curious as i'm keen for any feedback on the hid stuff. i'm also adding in the ability to send data to a hid device but that's not needed for a gamepad type thing ofc.

what config are u loading atm? mappings can be completely customised and aren't too tricky once u get your head round them. they're just based around writing snippets of code that deal with what happens when a message comes in that u are interested in.

...

i'm up for answering any question on using lua in midimasher anyway

you can't access midi clock atm. it's being decoded and used by the internal sequencer i've been working on but will need to make it available anyway now for the slicer stuff.

what data do u want to get from the clock? i presume not all the 24 ticks per beat... being able to capture() and do stuff on the beat via the midi clock is what i need and also wouldn't hurt to be able to get hold of the actual bpm in a variable for other use. so i can do something on each beat based on it.

writing my own mappings and functions atm.

hid is working fine, faders (potis on thumbsticks, etc...) are working properly now.

would be nice to add this function to the pool, as the HID-Faders only cover the first half of the way by default if you pipe them (e.g. you push the fader to half, and it already sends 127):

 function hid_fader(input_device, event_i, value_i, p)
	value_o = value_i/2
	send("cl", event_i, value_o)
 end

-- call it via:

 capture("gp", "fader1", ALL, 0, "hid_fader")

as a whishlist for the clock input:

- 24 messages per beat are not necessary in my opinion
- tempo [BMP] would be nice
- beat counter with reset function to set it to zero would be great!

i imagine usages like:
*click button*

do

beat 1:
beatmasher 1 beat

beat 2:
beatmasher 1/2 beat

beat 3:
beatmasher 1/4 beat

beat 4:
beatmasher 1/8 beat

beat 5-6:
beatmasher 1/16 beat
transform FX from 0 to 127
end

[zestoi]

writing my own mappings and functions atm.

hid is working fine, faders (potis on thumbsticks, etc...) are working properly now.

awesome did u have to use hidlearn(.exe) at all? it's not very clever for pots... it works if u leave the pot at it's max value, else u need to edit the bitmask after in the devices file and even then u need to change the 'type' from 'button' to 'fader'

would be nice to add this function to the pool, as the HID-Faders only cover the first half of the way by default if you pipe them (e.g. you push the fader to half, and it already sends 127):

 function hid_fader(input_device, event_i, value_i, p)
	value_o = value_i/2
	send("cl", event_i, value_o)
 end

-- call it via:

 capture("gp", "fader1", ALL, 0, "hid_fader")

will do also add that 'cl' device name in as a 5th argument (and also allow capture() to take a list of optional args after the function name) so then u can call like:

capture("gp", "fader1", ALL, 0, "hid_fader", "cl")

as atm the only way of making that generic would be to embed the function inline like this

capture("gp", "fader1", ALL, 0, function(input_device, event_i, value_i, p)
	value_o = value_i/2
	send("cl", event_i, value_o)
end)

i didn't have a hid device with actual pots on until last week when i realised i could run my old hercules mk2 in hid mode if i didn't install their drivers.

up till that point it was easy... i didn't support pitch bend (or any other hi res messages) and only midi, so *every* input and output had a max value of 127. what i'm doing now is adding intelligence in so it will automatically scale any value to the output based on the input and output ranges. i.e: in your case the 0-255 will get scaled to 0-127 and if you wanted to map it to a pitch bend message it would auto scale to the output range of 0-16383.

this will also have the nice side effect that a controller based on a gamepad can have twice the resolution for it's pots in traktor (or whatever app) if u use the 16 available pitch bend messages

as a whishlist for the clock input:

- 24 messages per beat are not necessary in my opinion
- tempo [BMP] would be nice
- beat counter with reset function to set it to zero would be great!

sure. the 24 ticks are processed internally in midimasher to work out the bpm and start of the beats but they won't all end up as 'events' that can be capture()'ed.

i'll make available a 'beat' event for each beat, that maybe cycles round values 1-16 or 1-8 or something? that would let u do what u want. i'll also store the actual bpm in some variable in case it's useful to get hold of it.

fantastic to get some feedback from some custom config code

[woorszt]

midimasher is great and unique tool. works perfectly with my launchpad. Already created my own mapping.

Just one thing: Can you please provide a changelog on your homepage?

[zestoi]

midimasher is great and unique tool. works perfectly with my launchpad. Already created my own mapping.

Just one thing: Can you please provide a changelog on your homepage?

cool i really haven't had any clue that anyone has been using it tbh. i see i get plenty of downloads when i grep the web server logs, but that's about it...

and sure, i'm commiting all changes using 'git' so i always know exactly what goes in, i'll make sure to add a changelog in future.

cheers for the feedback

[derschaich]

glad you're working on this for the community!

will continue posting functions that i consider helpful for everyone. 1/16 would be nice, although it might be wise to handle the clock events completely internally to prevent a potential overflow of the midi signal.

btw: do you want to keep this open source? - would be a WIN for the whole community!

EDIT:
+ this thread blows off, we should keep an eye open for other options of communication (maybe get an own subforum here on DJTT)

+ maybe lauching sort of MIDI-clips (timed via clock) would be a great thing for automation!

[zestoi]

glad you're working on this for the community!

cheers good to get some feedback too... apart from the last few posts here it's usually me just saying what changes i've been making

will continue posting functions that i consider helpful for everyone. 1/16 would be nice, although it might be wise to handle the clock events completely internally to prevent a potential overflow of the midi signal.

definitely posting any lua snippets of code here i think will be very useful... i do think the biggest issue with midimasher is that it'd quite daunting to get into for any non coder.

btw: do you want to keep this open source? - would be a WIN for the whole community!

if there's enough interest i may well do... up till now i've had very little feedback from anyone really. every now and again someone will come into this thread with questions, but they've been quite few and far between.

for now i want to keep control over the code and ofc it's only the core compiled stuff that people can't modify, but going open source in the future, if that makes sense, is def an option.

+ this thread blows off, we should keep an eye open for other options of communication (maybe get an own subforum here on DJTT)

i'm just happy to have any feedback for now... but who knows...

+ maybe lauching sort of MIDI-clips (timed via clock) would be a great thing for automation!

indeed it would

i mostly added in the midi clock decode for a new internal sequencer i've been working on. basically it lets u say "repeat this midi message on beat X.Y and repeat every 8 beats" and also the ability to dynamically clear them.

i want to be able to use the new remix deck stuff for programming beats basically... i think it should work ok and be tight enough but it's not at a testable stage yet.

u will also be able to say "send this midi on beat X.Y once" ofc for launching a midi clip. u can already specify a command to be sent out a certain number of milliseconds in the future like this:

send("traktor", "play_a", ON, 0, 2000)

but that's not quite useful for clip launching - tho the internals are shared.