Novation SL MkII and Reaper (MIDIOSC bridge)

[fundorin]

VSTLua is a VST that can run Lua scripts (midi, osc). It’s old, buggy and unsupported. It’s not as featured as Ctrlr, but it have bunch of preinstalled functions/utils and I had fun using it. http://www.hermannseib.com/VstLua/index.html
It wasn’t stable, so I’ve discarded it.
Sorry that I thought that those comments in demo panel were for me. 😉

[fundorin]

This code works:

View post on imgur.com

But the very moment I try to print variable named “value” outside of the if.then statement, Ctrlr crashes, either I’ve declared variable “value” earlier or not.

[atom]

Well i don’t know why it’s crashing yet, one thing i would do is not use the name “value” for your variables it might be thrown around in other places a lot, but i’m still looking into this, it’s very possible there are bugs theese fixes are done today @work in some spare time, i’ll get back to it.

[fundorin]

Thanks. As you might already know, .16 crashed, while .11 version just showed error message and duplicated it contents in console, so user could continue working with Ctrlr. There was also a bug that prevented selecting more that three elements on the panel with lasso (Ctrlr hanged). This bug stayed in the latest build and I’ve found another variation of it: selecting more than three elements with mouse, while holding “ctrl” button on keyboard also hangs Ctrlr.

P.S. Good advice about not using “value” as variable name. Changed it to “oscValue”, but Ctrlr still crashes. One of ten times it’s working fine and then crashes with the very same script. Still cannot find out, what actions causes this issue. Could this be because Reaper sends too many OSC commands or sends them faster then Ctrlr is able to handle at once?

[atom]

It’s crashing beacuse for some reason the new luabind/boost combo is not catching exceptions, i need to fix that.

[fundorin]

This is a simple code that should print path and type at first line and corresponding string value for every type of parameter at the second line:

onOSCMessage = function(path, types, arguments)
	
	console(path..' '..types)
	oscValue = string.format('%s', arguments[0])
	console(oscValue)
end

Here’s the console log – https://dl.dropboxusercontent.com/u/8162257/OSCFromReaper.txt
As you can see, output isn’t stable at all. Sometimes float arguments have string value and some other time string arguments have float value.
Maybe this will help you to understand better what is happening, atom.

I feel like it might be a good idea to return arguments of the function as formatted strings by default for any type of data and put it into the table, so then user can reformat it into any type he needs, afterwards.

I mean, something like osc[0] – path string, osc[1] – types string, osc[2]…[x] – argument strings.
Or, osc[0] – path string, osc[0][0] – types string, osc[0][1]..[0][x] – argument strings.

Table can start at 1 instead of 0, I don’t think that it matters much.

Or, maybe, values should be put in arguments table already formatted by their type.

For example, Reaper understands and outputs the following types of arguments:
n: normalized floating-point argument. 0 means the minimum value, and 1 means the
maximum value. This can be used for continous controls like sliders and knobs.

f: raw floating-point argument. The argument is interpreted directly, to set or
report a value.

b: binary argument, either 0 or 1. The device sets or clears the state when
sending the message. Can be used to emulate switches or momentary controls.

t: trigger or toggle message. The device triggers the action, or toggles the
state, when the pattern is sent with no arguments, or with an argument of 1.
The feedback values REAPER sends are identical to those sent for binary
arguments.

r: rotary. The device triggers the action in the forward direction when sent
with an argument greater than ROTARY_CENTER, and in the reverse direction when
sent with an argument less than ROTARY_CENTER. For some messages, the magnitude
of the argument affects the rate of change. REAPER does not send feedback for
these messages. (rotary_center could be 0 or 0.5)

s: string. These messages include a string argument. Many of these messages
are sent from REAPER to the device for feedback/display, but some can be sent
from the device to REAPER.

i: integer. These messages include an integer argument, and are sent from the
device to REAPER.

So, Reaper can accept all those types, but outputs strings and floats, mainly.

P.S. BTW, you’re using variable “type” in the panel, which is the name of Lua’s global function for detecting type of the variable. The same advice that you gave me about not using a variable, named “value”, – don’t use a variable, named “type”. 😉

[atom]

Yeah i notice i used “type” i’ll fix that

But there is a bug or some problem in there too, i think i might siwtch to JUCE’s OSC implementation and drop the liblo, i added this before JUCE had OSC support i think i’d rather use an already built in feature instead of adding additional libraries. This will change the API for OSC but i think that in the long run this will be a better idea. Let me know if this is going to be a big issue, i’ll try to keep the API as compatible as i can but there might be differences.

[fundorin]

For now, I didn’t implement any OSC related stuff in my panel, since it has issues with the string arguments. I’d better wait until you’ll fix it. It doesn’t matter, which API will be used in Ctrlr, but I also think that native OSC support might be a better idea than using liblo, even if it was around for quite long and was used in many other apps, including VSTLua.
I’m all for JUCE OSC and for any API changes that you may find necessary. Since it seems that there’s no one else is using OSC in Ctrlr, apart from myself, from the time it was implemented in Ctrlr, I think that you can change everything and start from a blank page with OSC, if needed. It’s just hard to wait for me.
I think that I’ll start building my custom MIDI controller tomorrow, while waiting for OSC implementation in Ctrlr. 🙂

[fundorin]

-del-

[goodweather]

As many things in Ctrlr are based on Juce, it is a smart move to also do it for OSC 🙂

[atom]

I uploaded a new build, this one has lua 5.1.4 and handles exceptions so it shouldn’t crash (exit) but catch errors and show error dialogs. It looks like sometimes the float/integer value can be ‘nil’ so you need to check before trying to do anything with them. Strings should be fine.

[atom]

I will add the JUCE OSC stuff but alongside this implementation and you’ll be able to choose what API you want to use, i don’t want to break anything, often people use it just don’t say anything about it here.

[fundorin]

Thanks for new build. I’ve got nil error immediately (the second time I chose track in Reaper, actually) with demo-osc panel. Then, when I’ve tried to save this panel with a new name, to make some changes, Ctrlr crashed with this message:

View post on imgur.com

[fundorin]

The same thing happens with osc feedback as I’d reported before. The same value (and type) often repeats for different osc commands from host. I’ll wait for new OSC implementation, then.

[fundorin]

I confirm that selecting and dragging issue is gone in the latest version of Ctrlr. Thanks. Are there any news about JUCE OSC implementation, yet?

[Author]

Posts