Rev 1193 MidiMessage Issue

[dasfaker]

There seems to be a problem with midiMessage:getData():getRange

The data I get with with midiMessage:getData() is “f0 41 10 6a 12 03 00 00 00 42 72 61…” (Correct)

But if I use midiMessage:getData():getRange(00,77)

The message I get is “b0 c9 cd 03 3e 00 00 00 5b 31 38 3a…” (Wrong)

It should be the same data

[dasfaker]

I see what happens, look at the sequence:

>>> console(“”..PatchCommonSyx:getRange(0,1):toHexString(1))
f0 f0
>>> console(“”..PatchCommonSyx:getRange(0,2):toHexString(1))
b0 2e f0 41
>>> console(“”..PatchCommonSyx:getRange(0,3):toHexString(1))
a0 07 22 f0 41 10
>>> console(“”..PatchCommonSyx:getRange(0,4):toHexString(1))
50 17 45 04 f0 41 10 6a

The bold data is correct, but for each correct byte, another byte is added at the beginning of the message

[atom]

Here is my method:

myMethod = function(mod, value)
	midi = CtrlrMidiMessage({0xf0,0x41,0x10,0x6a,0x12,0x03,0x00,0x00,0x00,0x42,0x72,0x61})
	console ("---------- snip")
	console(midi:getData():getRange(0,1):toHexString(1))
	console(midi:getData():getRange(0,2):toHexString(1))
	console(midi:getData():getRange(0,3):toHexString(1))
	console(midi:getData():getRange(0,4):toHexString(1))
	console ("---------- snip")
end

and the output from LUA

LUA>> ---------- snip
LUA>> f0
LUA>> f0 41
LUA>> f0 41 10
LUA>> f0 41 10 6a
LUA>> ---------- snip

Looks ok to me i’d need a complete example.

[dasfaker]

Your example in an empty panel
---------- snip
f0 f0
48 db f0 41
38 dc bd f0 41 10
c8 14 4b 06 f0 41 10 6a
---------- snip

[Llamatron]

I got a similar issue, it’s what’s causing my sysex dump problem I mentionned in another thread. After

programData = midiMessage:getLuaData():getRange(5,51)

where midiMessage is a 57 bytes long midi message, programData displayed with

console (programData:toHexString(1))

is aproximately twice as big and got some seemingly random numbers as the exact same sysex data results in different numbers.

[msepsis]

I’ve had to stick with 1184 here as with anything later than that my program names are displaying as numbers 0-9 with the method I had gone with (value 32-127 combobox per letter) to display program names on my panel.

I haven’t had the bandwidth these past few days to narrow the cause down but maybe it’s related. I’m sure theres a better way these days to display a program name in ctrlr anyway.

Then again probably some of the stuff I haven’t been able to get working (that should!@$) in 1184 could be due to something wrong in 1184 🙂

 

If anybody has any tips on the combobox displaying 0-9 instead of the ascii characters I have assigned in the combo contents (32-127) let me know, otherwise I’ll try narrowing that down later possibly all completely unrelated to the aforementioned midiMessage reports but since we’re talkin 1193 here thought I’d add my 1 1/2 cents.

 

ahhh.. another friday night of nice quiet coding 🙂

Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

[atom]

I can’t think of a reason why this is happening. Is this the 64 or 32 bit build of Ctrlr ?

[dasfaker]

XP 32 here

[Hecticcc]

I can confirm the ascii bug,  all characters that have values coming from an incoming hex-message are acting up. Instead of all characters i sometimes see one character being displayed, and stepping up and down the values produces different characters for the same values.

Internally updated messages (ie value comes from a modulator, not midi-in) work correctly.

 

I also get strange behaviour from a script that works in 1183, it looks like ctrlr makes an internal midiloop with a 3-byte message, and the timestamp is a negative value …

 

*edit*

 

win 7 ultimate 32bit bare install

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

My weekly radioshow @ Belgium's best local radio station - - - - - -
Updates and news about the Emu eos sampler panel

[msepsis]

32 bit winXP here. If I get a chance today to look at what was going on through midi monitor vs what should be going on I’ll follow up. definitely something screwey and it was noticeable immediately after receiving the first dump from the synth to the panel – however the waveforms from wavetables were drawing perfectly fine to a uiCustomComponent ..

when i get a chance i’ll follow up with more detail.

Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

[Llamatron]

64bits Windows 7 here, and I confirm the bug is in getRange as removing it results in the values being where they’re expected

[atom]

I’ll work on that issue ASAP, possibly tomorrow or friday. I’m at home for christmas and without access to any decent computer to code. I’m aware of the problem and will try to fix it. Please be patient.

[msepsis]

Thanks atom, take your time man. I’ve got plenty to work on and 1184 is working for me… mostly.

On that note i’ve already reported the details in a PM to atom along with some example panels, but be careful when saving to .panel files in 1184. I’m not completely sure how the heck it happened but one of my panels lost ALL of it’s Lua scripts after saving incremental .panel files from ctrlr 1184. I was experimenting with some things so maybe I pushed it too far but everything was working just fine while in ctrlr, until i crashed and went to open any of the panels I had saved during that 3 hour session – none of them contained any Lua. The most recent file i had saved that worked ok was a bpanelz file, so take that for what its worth.. For me, I’m just saving to bpanelz not .panel) and closing/restarting ctrlr after making any progress I want to ensure does not get nuked.

It wasn’t the end of the world (was just experimenting, bug testing and making minor tweaks) but want to save anybody else the trouble if it’s something that can be reproducible.

Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

[atom]

I still can’t reproduce this, i tested it with program dumps from my DSI MOPHO. Anyway can someone paste the entire data path, that is from the creation of the data object until the data you are fetching is wrong. When is the MemoryBlock object created (if ever), how it’s created, or is it just data from an incomming MIDI message in the method that’s called on every incomming midi for the panel.

I’m also uploading another build just to make sure that everything is built correctly it has a number 1194. It’s possible i screwed up something during buildtime. Please let me know.

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

[msepsis]

I’ll try to follow up with what you’re asking for later this eve when I’m next to synths. How many bytes does the DSI morpho’ program dump contain?

For me, it seemed the first 100 or so modulators by index were correct on the panel after the first program dump (from the synth to the panel), the rest were fubared.. each additional program dump seems to “get worse”, by the fourth or fifth dump to the panel every modulator was WAY off.

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

Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

[msepsis]

Wow. Yeah, for me, here the issue is resolved. And then some.

Atom. I no longer need to re-request the first 256 byte dump after 30 seconds idle time. Whatever that hitch that’s been there since like rev 600 is gone.

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

Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

[msepsis]

Apparently not able to edit my earlier posts at the moment(weird), so… that old 30 second idle bug is still there contrary to what I seemed to find initially. I must have only waited 29 seconds to change patches or something.

Regardless, the good news is this version is fully usable for me, any ascii character bug is gone, program and other data dumps from the synth are coming in properly and my custom components are no longer drawing star maps… which is a good thing, although that did look cool as hell.

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

Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

[Llamatron]

I confirm that my getRange bug seems gone

[Author]

Posts