Is there any way to print the values of MIDI CC messages, specifically the global volume (velocity)?:
CC#07 | Volume (Control the global volume) | 0-127
Is there any way to print the values of MIDI CC messages, specifically the global volume (velocity)?:
CC#07 | Volume (Control the global volume) | 0-127
Is this a scripting related question or a feature suggestion for the MIDI panel?
In case it’s the first, then you can make it yourself - make a tool that opens a connection to the device, and parse the incoming messages:
https://github.com/renoise/xrnx/blob/master/Snippets/Midi.lua
Is this a scripting related question or a feature suggestion for the MIDI panel?
In case it’s the first, then you can make it yourself - make a tool that opens a connection to the device, and parse the incoming messages:
https://github.com/renoise/xrnx/blob/master/Snippets/Midi.lua
It’s a scripting question.I’m trying to use OSC to trigger notes, but at the same time to define the velocity of the MIDI keyboard.
/renoise/trigger/note_on(instr(int32/64), track(int32/64), note(int32/64), velocity(int32/64))
As I now have my tool, speed takes the value of a slider or a rotary.I would like to add an option to take the velodity of the MIDI keyboard.
Imagine you want to build a tool with 64 pads,similar to the FavTouch window module, of the PhraseTouch tool.FavTouch allows you to route specific notes in each pad. But it would be necessary to define the velocity of the MIDI input, so that it would take this value in case it existed, otherwise, it would take the value of the rotary.So, I do not know if the best way is to mix OSC stuff with MIDI input stuff. I’ve never done.
The rest of values (instr, track, note), are values that come from a modifiable table.Each pad is a button with middi_mapping ,and it is necessary to map each button through CTRL + M.So I do not quite know how to focus it to correctly define the velocity of pulsation.
I’ll take a look at the link, but I do not know if I’m on the right track…
If I could print the volume value of the image capture, maybe it might work.But I do not know if the API allows you to mix things from OSC with MIDI Input.
As I now have my tool, speed takes the value of a slider or a rotary.I would like to add an option to take the velodity of the MIDI keyboard
Yes, then you need to define your own MIDI input ports in the tool. You’re on the right track
Yes, then you need to define your own MIDI input ports in the tool. You’re on the right track
Ok, thanks!I have advanced a little here. I have deduced this function, which equates a rotary (PHT_FAV_ROT_VEL) to message[3] (velocity):
function pht_midi_in()
local inputs = renoise.Midi.available_input_devices()
local midi_device = nil
if not table.is_empty(inputs) then
local device_name = inputs[1]
local function midi_callback(message)
--assert(#message == 3)
--assert(message[1] >= 0 and message[1] <= 0xff)
--assert(message[2] >= 0 and message[2] <= 0xff)
assert(message[3] >= 0 and message[3] <= 0xff)
--print(("%s: got MIDI %X %X %X"):format(device_name, message[1], message[2], message[3]))
--if ( ??? ) then
vws.PHT_FAV_ROT_VEL.value = message[3]
--end
end
midi_device = renoise.Midi.create_input_device( device_name, midi_callback )
-- stop dumping with 'midi_device:close()' ...
end
end
The rest of the canceled lines seem unnecessary for this case. For the moment the function registers both when pressing and when releasing.Is there a condition to ignore the release? I mean, something like that:
if ( ???.pressed ) then
vws.PHT_FAV_ROT_VEL.value = message[3]
else
return
end
or
if ( ???.note_on ) then
vws.PHT_FAV_ROT_VEL.value = message[3]
else
return
end
Any way to do this?
If you are going to detect which notes are pressed and released, you will have to consider that multiple piano keys can be pressed and release in any order…
You can’t just assign this to a single variable. Instead, create a voice manager - something dedicated for handling this.
Some inspiration/code:
https://github.com/renoise/xLib/blob/master/classes/xVoiceManager.lua#L251
PS: Also, be aware that with MIDI, it’s possible to have a note-on event with zero velocity. This should be interpreted as a note-off.
If you are going to detect which notes are pressed and released, you will have to consider that multiple piano keys can be pressed and release in any order…
You can’t just assign this to a single variable. Instead, create a voice manager - something dedicated for handling this.
Some inspiration/code:
https://github.com/renoise/xLib/blob/master/classes/xVoiceManager.lua#L251
PS: Also, be aware that with MIDI, it’s possible to have a note-on event with zero velocity. This should be interpreted as a note-off.
I have been experimenting with this:
function pht_midi_in()
local inputs = renoise.Midi.available_input_devices()
local midi_device = nil
if not table.is_empty(inputs) then
local device_name = inputs[1]
local function midi_callback(message)
--assert(#message == 3)
--assert(message[1] >= 0 and message[1] <= 0xff)
--assert(message[2] >= 0 and message[2] <= 0xff)
assert(message[3] >= 0 and message[3] <= 0xff)
--print(("%s: got MIDI %X %X %X"):format(device_name, message[1], message[2], message[3]))
--if message then
print(message[1])
--if ( message[1] == 153 ) or ( message[1] == 144 ) then
if ( message[1] == 0x99 ) or ( message[1] == 0x90 ) then
vws.PHT_FAV_ROT_VEL.value = message[3]
end
end
midi_device = renoise.Midi.create_input_device( device_name, midi_callback )
-- stop dumping with 'midi_device:close()' ...
end
end
if ( message[1] == 0x99 ) or ( message[1] == 0x90 ) then
vws.PHT_FAV_ROT_VEL.value = message[3]
end
message[1] == 0x99 (pad)
message[1] == 0x90 (piano)
These are the values to note_on (0x80, 0x89 to note_off).I assume that each MIDI controller will use a different value for note_on and note_off. It is not like this?I suppose this would not be valid for simultaneous pulsations.From what I see, this can be quite difficult to define, with all types (.TYPE.NOTE_ON, .TYPE.NOTE_OFF, .TYPE.KEY_AFTERTOUCH).
@danoise: I have a offtopic question: How exactly does the midi event processing in LUA work? I have seen there is a on_idle loop in your xMidiInput.lua, and seems to collect so far happened midi messages? Is there a way to receive time critical / live midi messages, too? If so, could you show me the location in your lib? Thanks!
@danoise: I have a offtopic question: How exactly does the midi event processing in LUA work? I have seen there is a on_idle loop in your xMidiInput.lua, and seems to collect so far happened midi messages? Is there a way to receive time critical / live midi messages, too? If so, could you show me the location in your lib? Thanks!
[sharedmedia=core:attachments:8096]
In the image capture above there are 3 hexadecimal values in the DATA column.I take the second line (99 24 7F)
99 (pad) = note_on, 24 = note, 7F = velocity (pressed)
89 (pad) = note_off, 24 = note, 40 = velocity (released)
For press velocityto play notes, release velocity seems to be unnecessary,same as in OSC.
With the functions of this link you can print these values instantaneouslyhttps://github.com/renoise/xrnx/blob/master/Snippets/Midi.lua
print((“%s: got MIDI %X %X %X”):format(device_name, message[1], message[2], message[3]))
Is not this what you ask?I have not found detailed documentation on this matter. For example,how to define this directly:.TYPE.NOTE_ON,.TYPE.NOTE_OFF,.TYPE.KEY_AFTERTOUCH.
It is possible to mix this which is for the MIDI Input (/Snippers/Midi.lua) with the OSC code. At the moment, it seems to work well and fast.
I’m not too sure about all this. So if I say some error, someone correct me…
Ah yes, thanks Raul.
Is there a way to receive time critical / live midi messages, too?
Not “a way”, it’s simply how it works. OSC/MIDI processing exists in the realtime/player thread of Renoise, and handing it over to Lua carries only a tiny penalty.
There is one, but in my own tests you don’t even see the difference when recording unquantized notes @ LPB4/12x BPM on a reasonable powered rig…here, the resulting note delays are simply the same.
So if you had a hardware box which generated a high-def clock signal, you could potentially use that to “drive” your tool to do things programmatically (without user interaction). Ahh, workarounds