[TK.]

The interesting point is, that my first assumption was correct, because the crash also happens at my side when the MIDIbox FM panel receives some data.

It’s related to some mem_block copy stuff that I copied from the Novation A Station panel.
After handling the received SysEx data differently my panel is working now and doesn’t cause the crash anymore.

However, I think that Sjoerd has a similar problem.

Best Regards, Thorsten.

• This reply was modified 11 years, 4 months ago by TK..

[TK.]

I Sjoerd,

yes, I’m interested on the crash report.

It shouldn’t be required to remove the old application.
I think that there are two possible reasons:

1) you are using a panel which contains invalid components or Lua code which can’t be handled by the newer Ctrlr version. This never happened at my side (/edit: doh! now I was able to reproduce this as well), but it isn’t impossible that during the startup phase such a panel could cause a crash.
In order to test this, just open the older Ctrlr version, close all panels, close Ctrlr.
And then open the newer Ctrlr release.

2) maybe more likely: I’ve compiled Ctrlr under Mountain Lion, and I’m unsure if the binary would also run on older MacOS versions.
I tested it on two different Macs, but both are running with the latest MacOS release.
Which one are you using?

Best Regards, Thorsten.

• This reply was modified 11 years, 4 months ago by TK..
• This reply was modified 11 years, 4 months ago by TK..
• This reply was modified 11 years, 4 months ago by TK..

[TK.]

” title=”Confused” />

[TK.]

Could you please give us a [b:2edchx4u]vision[/b:2edchx4u] for a consistent Windows and Mac release with all outstanding issues fixed?
Somehow I feel that you don’t listen to the users – we are [b:2edchx4u]lost[/b:2edchx4u]!

Best Regards, Thorsten.

[TK.]

I had a similar issue with my MIDIboxFM and MIDIboxSID panel, and debugged the Ctrlr code today to understand the root cause and to find a solution.

The reason for this issue: due to the (new) asynchronous event handling, which was introduced after r946, the "luaPanelLoaded" callback will be executed before all value changes have been processed.

The fix: in CtrlModulator.cpp, at the end of CtrlrModulator::restoreState, before calling the setRestoreState function, insert following function call:

[code:fv5tyjta]
void CtrlrModulator::restoreState (const ValueTree &savedState)
{
...
processor.handleUpdateNowIfNeeded(); // TK: synchronous update requrired
setRestoreState(false);
}
[/code:fv5tyjta]

This will process the code in CtrlrModulatorProcessor::handleAsyncUpdate() immediately before the "luaPanelLoaded" callback is executed.

Atom will add this change into Ctrlr, it will solve at least the Lua runtime errors (during load) of my own panels. ” title=”Smile” />

Best Regards, Thorsten.

[TK.]

I had the same problem and it was not related to a caching issue: viewtopic.php?f=48&t=869#p4834
You’ve to use the "Upload" function, and not the "Update only" function to update your panel in the DDB

Best Regards, Thorsten.

[TK.]

replied.

[TK.]

My personal preference are .dmg files, because they allow me to use multiple installations in parallel.

Best Regards, Thorsten.

[TK.]

There is a similar disaster with my MIDIbox panels: they are neither compatible to r1022 (for Windows, I can’t use it by myself since I’m working on a Mac), nor r965 (for Mac, this version doesn’t handle Lua scripts correctly as reported somewhere else in the forum), nor the "stable" releases for Windows/Mac/Linux.
Therefore I still have to provide older releases for Windows/Mac (r945/r946) on my server until the nightly releases are aligned again.

It seems that configuration management isn’t your strength! ” title=”Wink” />

However, could you please update the nightly Mac build?
This would allow me to migrate my panels to the most recent Ctrlr versions.

Best Regards, Thorsten.

[TK.]

Your assumption on the checksum calculation is correct – it’s just the sum of a certain byte range limited to 7bit, and in distance to common synths the checksum is not inverted!

This is what the Waldorf documentation (posted by Zeoka in the 6th posting) is saying about this topic:

---

1.3.6 Checksum
MIDI isn’t a very reliable transport medium. Therefore longer sysex messages are protected by a check- sum, which is the sum of all sysex bytes from CMD to the end of MSG truncated to 7 bits (modulo 127 — [b:1ovibys8][TK:CORRECTION] very likely modulo 128![/b:1ovibys8] — ). If the sum calculated from the received bytes and the transmitted checksum differ, something has gone wrong. When the checksum is evaluated, a wrong checksum will cause the complete message to be ignored.

Notes
• A checksum of 7Fh is always accepted as valid. This can be used if data is altered manually or produced by MIDI control surfaces with limited capabilities. This option should not be employed by editor programs to skip the checksum calculation.

---

The interesting point: it seems to be a bug in the RackAttack firmware that the 0x7f checksum isn’t ignored.
Or it’s a handling error by Zeoka. However, the Waldorf specific checksum calculation could be easily added to Ctrlr, and the specification recommends this for editors anyhow! ” title=”Wink” />

Once I find the time I will try the dummy checksum handling on my MicroQ and Blofeld, just to doublecheck if the documentation is true for these synths… I must say, that I would like to check this with a RackAttack as well – at least in three or four jam sessions (having some fun with the percussion sounds ” title=”Wink” />)

Best Regards, Thorsten.

[TK.]

"zeoka":y6mg7lvc wrote:

Finnally cc’s work : it’s my fault
How i put this ? in the sysex formula ? Must i write someting for Ctrlr ?
[/quote:y6mg7lvc]

In a previous posting you wrote that following SysEx command changes the volume of Sound 1
[f0 3e 11 00 20 20 00 00 35 5a 4f f7]

In order to control it from a slider with a dummy checksum, please try:
F0 3E 11 00 20 20 00 00 35 xx 7F F7

Ctrlr will replace xx by the slider value, and the next byte (7F) is the "dummy" checksum, which will hopefully be ignored by RackAttack.

Best Regards, Thorsten.

P.S.: 0x7f is the C-style format for a hexadecimal value, but in the Ctrlr GUI you enter the value without preceding "0x"

[TK.]

Great! ” title=”Smile” />

Best Regards, Thorsten.

[TK.]

You could try 0x7f as checksum – most Waldorf synths will always accept the SysEx message in this case.

Best Regards, Thorsten.

[TK.]

I think that I found the problem: it was sitting in front of the keyboard! ” title=”Wink” />

In order to upload a new version, I selected the "Update only" option instead of "Upload", because I wasn’t sure about the difference, and wanted to avoid that a new panel entry could be created with "Upload", so that the old version would have to be removed by you.

But it seems that "Update only" updates the DDB informations, and "Upload" is doing the actual update of the complete panel, right?

Now I uploaded the latest version of the MIDIbox FM panel, and it was immediately downloadable from the second computer.

Best Regards, Thorsten.

[TK.]

[TK.]

Here’s a copy of the r946 build for MacOS:
http://www.ucapps.de/tmp/Ctrlr_r946.dmg

Best Regards, Thorsten.

[TK.]

I found the "leak": it’s not Lua itself, but the Console window.
Than more messages are print, than slower the GUI.

I had a similar issue in an own Juce based application a while ago, and solved this by overloading the ListBox class:
http://svnmios.midibox.org/filedetails. … LogBox.cpp

In difference to ListBox, it doesn’t store the text in a (huge) string, but stores each line in an array: Array<std::pair<Colour, String> > logEntries;
This allows to log thousands of messages without affecting the GUI performance. ” title=”Smile” />

I would recommend to use this method for the MIDI monitor and the Lua Console

Best Regards, Thorsten.

[TK.]

Thanks again!

Btw.: concerning the handing of negative values, I read somewhere in the forum about following solution which I’m also using in my panel.

In following example we want to range between -64..63, and send 0..127:

Component: set minimum value to -64, and maximum value to 63 -> this is the displayed value.
Modulator, first entries (I think that I don’t need to quote the descriptions): modulatorValue + 64, midiValue – 64

Advantage: the modulator receives/stores/sends exactly the same value which is used by the synth and transfered via SysEx, no special handling required in the Lua script.

Best Regards, Thorsten.

[TK.]

Thanks for the inspiration!
Using a custom and group index which is embedded into the modulator (or component) would also help me on my next panel where much more parameters (with up to 3-dimensional structures) have to be maintained.

How do you get these indices from Lua?
Could you please post a small code snippet?

Best Regards, Thorsten.

[TK.]

In the existing panels I found two different solutions so far:

1) create a SysEx string and send it directly via sendMidiMessageNow.
Example:
[code:y5nzl4fz]
— request ENS dump
midiDevice = panel:getGlobalVariable(1) — this is k1
mEns = CtrlrMidiMessage( {0xf0, 0x00, 0x00, 0x7e, 0x49, midiDevice, 0x01, 0x78, 0x00, 0x00, 0xf7} )
panel:sendMidiMessageNow(mEns)
[/code:y5nzl4fz]

2) send the binary value to a hidden (invisible) component with a modulator which sends the SysEx string (I call it "satellite" since it acts like a transceiver which hovers above the buttons ” title=”Wink” />
[code:y5nzl4fz]
sat = panel:getModulatorByName("OP1FlagsSatellite")
if sat ~= nil then
notify_vst_host = false
notify_midi_device = true
notify_component = true
sat:setModulatorValue(value, notify_vst_host, notify_midi_device, notify_component)
end
[/code:y5nzl4fz]

I’m unsure which method is better.
The second one is a bit cumbersome, but it might have advantages if the resulting value should be handled on an alternative way (e.g. retrieve the last sent value for a patch dump).

Best Regards, Thorsten.

[Author]

Posts