[Possemo]

@samoth: well said. I would add here, that those who take money for ther panels (which is allowed by Roman and probably somewhat legal) should think about what Ctrlr in fact is: It is an open-source project which, until now, has never gone beyond beta-state. There are just “nightly builds” which to my understanding are alpha-releases, not even beta-releases. The most stable build v5.3.201 could probably be seen as a beta-release. So, if you are selling a panel you are selling an unfinished piece of software. Even worse, you have no full control over it and you cannot tackle problems reported by customers which are related to Ctrlr itself (such as e.g. not being compatible with new OS versions).

[Possemo]

Working here on Win10 2004 and Reaper v6.13.

[Possemo]

I have no experience with LogicX but in general in the DAW you have to disable the midiports you are using with Ctrlr and select them in the midi menu of Ctrlr. Then set midi-thru option “pluginhost to output” in order to get the DAW track conneted with the synth.

[Possemo]

There are also other ways to do it (in a Lua script) but that’s the way I would do it too. Wow! Lexicon uses 16 Bit parameter resolution. I’d say that this is a bit crazy – 65536 values, phew. IMHO in most cases 8 Bit would be enough (256 values) and in special cases you could use 12 Bit (4069 values) or 14 Bit. Btw. standardized MIDI Pitchbend parameter has 14 Bit. They probably saw that 7 Bit is not enough for the Pitchbend parameter. On the other hand 7 Bit (128 values) is a bit sparse. Most parameters could benefit from 8 Bit res…

[Possemo]

If you want to use sysex messages be aware that Roland synths do need a checksum even for the shortest sysex string. Roland is rather paranoid here. IMO it is pretty useless. I believe they started it at the D-50 / LA-Synthesizer line and kept it until todays recent synths. Look at a free editable panel for any Roland synth from the 90ties on how you do it in Ctrlr. Fortunately you don’t have to calculate it yourself. Syntax looks like this:

F0 41 10 57 12 03 00 03 32 xx z5 F7

“xx” is the value of the modulator
“z5” is the checksum. “z” means Roland-Checksum, “5” means it sums up five bytes.

That’s it. Very easy if you know how to do it.

[Possemo]

No, you don’t understand. It is not possible to use Ctrlr with any tablet/smartphone. There are versions for Windows, Linux and Mac. That’s it.

[Possemo]

No this is not possible, you confuse OSX with iOS.

Mac desktop computer: OSX
iPad/iPhone: iOS

These are completely different operating systems. But fyi Apple plans to trash Intel processors on Macs in favor to ARM cpus like their iPads/iPhones already have. So maybe in future there will be only iOS for both tablets/smartphones AND desktop computers. But…that will be the time when there will be no Ctrlr for Macs anymore 🙁

[Possemo]

@rotomtom: yea it is interesting I will look into it (virtual ports and midiox with cubase) when I find the time. Thanks for the info.

@the elf: Hmm, you probably mean, when you turn knobs the correspronding knob in midi-designer updates to display the value. That’s nice but to get real bidirectionality midi-designer would need some kind of scripting language where you can process the sysex-dump. Too bad it has no scripting capabilities, otherwise I would buy a second-hand ipad and would give it a try…

[Possemo]

This is interesting, but let me ask – what is the advantage using virtual ports and midiox?

[Possemo]

So the device sends individual sysex when turning knobs, that’s nice. Ctrlr should check automatically when an incoming sysex matches a slider’s sysex, but this feature is not very “stable” I mean it sometimes does not work. In your case it could be because you are using uiFixedSlider. Maybe try uiSlider with adjusting the fields “Expression to evaluate…”

dnaldoog talks about using Ctrlr’s built-in Lua script language. With Lua, possibilities are nearly unlimited but it requires you to build code – very easy code though. Lua in Ctrlr is a great script language to start coding.

Such things like your screenshot of a graphical display of the equalizer is not prebuilt in Ctrlr. You would have to do that with Lua scripts using the graphics features of the Juce library.

[Possemo]

@ea1ddo: you probably want that the slider reacts when turning knobs on the deq2496 panel. Are you sure that the device sends individual sysex messages? Maybe it just sends complete dumps (such as almost all devices), then you have to follow dnaldoogs advice.

And then, if I look at the sysex implementation:
http://keycorner.org/pub/midi/ultracurve/DEQ2496_MIDI_Implementation_V1_4.pdf
I don’t get your sysex message. According to the manual you edit “PEQ gain left”:

1 0,1 63…72 1 0…105 +15…-60 dB (-0.5/-1 dB) gain left
1 0,1 73…82 1 0…105 +15…-60 dB (-0.5/-1 dB) gain right

But these gains go from +15 to -60…?!

[Possemo]

My SuperJX-panel is using NRPN on more than 160 parameters and is working without probs. I guess it depends on how well it is implemented in the firmware of the synth. The SuperJX firmware v4 is a recent update/fix by Fred Vecoven, a skilled firmware specialist.

In the case of the SuperJX the amount of data is slightly smaller on NRPN even when always sending the CtrlrNr:

NRPN 9 Bytes:
b0 63 00
b0 62 00
b0 06 00

Sysex 10 Bytes:
F0 41 39 00 24 20 01 0B 00 F7

Well, it shouldn’t be that big of an advantage.

[Possemo]

I see. I think in most cases NRPN has no advantage compared to Sysex. The numer of bytes transferred is about the same, that is if you always send the Controller-Number together with a value change. This probably was not the way it was meant to be done. With Lua you could do a very efficient method, only sending the MSB/LSB Ctrlr-Nr. when the Controller changes. Anyway when you automate parameters and you change several controllers at once with NRPN there could always be a risk that parameters collide and some CC6 will not edit the right Ctrlr-Nr. With Sysex this is not possible.

[Possemo]

Ok I quickly read these explanations by Phil Rees. Mhh.. I have to say that I do not share his opinion but I see the point. E.g. “If the active parameter number is left open, and the equipment is not turned off, a parameter could remain set for years! A rogue Data Entry message on the corresponding channel could then cause unintended changes.”
First: We all turn off our equipment, don’t we?
Second: I don’t send “rogue” midi data… but then.. it would be a big coincidence that it would mess up the “still active” parameter.

That may be a matter of preferences. It is true that once the parameter is selected (CC99 and CC98) you just have to send CC6 to edit the value of this particular parameter. But – would you really send “rogue, senseless” CC6? Well for live setup where you want to be 120% sure that everything works as it should, that may be a point to consider. I’d prefer to send the minimum number of data through midi, but that’s my personal preference.

After all: good point anyway. I didn’t knew this “reset” message.

[Possemo]

Hey dnaldoog, you seem to have mixed up NPN and NRPN. You use either CC99 and CC98 (NRPN) or CC101 and CC100 (RPN) but not both together.

NRPN for Vibrato Rate would be like this:

CC,ByteValue,MSB7bitValue,99,-2
CC,ByteValue,LSB7bitValue,98,-2
CC,Default,Default,6,-1

No need to add the LSB-Part as the VS1 only seem to need MSB (CC6 at the end).
As Vibrato goes from -50 to +50 I would use an uiFixedSlider and enter the values like this:

According to the manual range is from 14 to 114 (Hex 0E to 72)

-50=14
-49=15
…
0=65
…
+50=114

This way WYSIWYG (what you see is what you get).

[Possemo]

It is some time ago when I found that getBit and setBit does actually work. If I remember well it needs a boolean (true or false e.g. bit set or not set). So, depending on the code it could make more sense to use getBitRange where you could directly use values or variables.

Edit: Ah, no as you said it is not implemented. Only setBit.

• This reply was modified 3 years, 10 months ago by Possemo.

[Possemo]

For bitoperations I too am using biginterger. For me it is easier to understand without loops:

	-- get values from Nibble in Byte 55 **********************************************
	local byte55=BigInteger(DumpData:getByte(49))

	Byte55bit1=byte55:getBitRangeAsInt(0,1)
	panel:getModulator("Sync_Switch"):setValue(Byte55bit1,false)

	Byte55bit2=byte55:getBitRangeAsInt(1,1)
	panel:getModulator("Trigger_SingleMulti"):setValue(Byte55bit2,false)

	Byte55bit3=byte55:getBitRangeAsInt(2,1)
	panel:getModulator("LFO_ToFilterCutoff"):setValue(Byte55bit2,false)

At the time when I made this I didn’t knew :getBit(bitnumber) which would have been even easier.

All biginterger options:
https://docs.juce.com/master/classBigInteger.html

Ctrlr probably does not support all of them but the most important ones are there.

bit.band would be another way to do it. For me it is less easy to understand but once you get into it it works quite well.

[Possemo]

Strange – my suggested settings do work on my setup, it sends values 0 and 7f. If I am not mistaken you are on Mac. The Mac version has some addidional quirks compared to the Windows-Ver, maybe this is one of them.

Btw. xx is just for sysex messages, on other messages -1 is the value and -2 ist the controller number.

[Possemo]

it works but it is a bit complicated. CC’s are much easier to setup, see my screenshot. It wouldn’t hurt to study the demo panels either 🙂

Attachments:

You must be logged in to view attached files.

[Possemo]

damien wrote:

Error message: [string “midiMessageReceived”]:19: attempt to call method ‘getByte’ (a nil value)

It’s probably coming from the very top of the script.

The error message tells you that the error is on line 19. Unfortunately, error messages are no always that clear.

[Author]

Posts