Forum Replies Created
-
Posts
-
all bit functions will be back in next builds, i will fall back to lua 5.1 since 5.3 is giving way to many issues to fix.
Ok, that’s good news (I think). What are your plans with CtrlrLuaBigInteger?
Will it stay, or is it better to use the bit library in Lua code for my panels if future compatibility is important? I never used CtrlrLuaBigInteger myself, but there other people in this forum using it.In my Reface DX, Korg 707, and Korg DS-8 panels I used a lot bit.rshift() bit.lshift() and bit.band()
I am now rewriting my lua code using code that seems to work on both my Linux and Windows boxes, and using different releases of Ctrlr and LUA.
Now I am using only * / ^ % and math.floor() to achieve the same results.bit_rshift = function(x, y) return math.floor(x / (2 ^ y)) end bit_lshift = function(x, y) return x * (2 ^ y) end— the following bit.band() replacement
— only works if y=1, 3, 7, 15, 31, 63, 127, 255
— but that was just what I needed in my Lua code anywaybit_band = function(x, y) return x % (y + 1) endUsing combinations of these functions I was able to do all my bit and byte manipulations, without using CtrlrLuaBigInteger or the bit library, and with the best compatibility on different systems and Ctrlr/LUA versions.
FB01 YES PLZ I LUV U
Be patient … those will not happen tomorrow, but it is on my todo/wishlist.
I think I know how to do it, I am quite familiar with the (sometimes strange) SysEx implementation of the FB01. But lack of free time is always a problem 🙂But this is all slightly off-topic here.
I am (re)working on my Reface DX Ctrlr panel. It used some simple bitoperations. I was able to rewrite my bit operations without using the bit library and without using CtrlrLuaBigInteger. I decided to only use simple standard lua integer divisions (//), modulo (%), and multiplications. That should make my panel work on both older and future versions of Ctrlr I hope.
Unfortunately it doesn’t. It almost looks like every version of Lua is shipped with a different way to handle bitwise operations … 🙁
I am (re)working on my Reface DX Ctrlr panel. It used some simple bitoperations. I was able to rewrite my bit operations without using the bit library and without using CtrlrLuaBigInteger. I decided to only use simple standard lua integer divisions (//), modulo (%), and multiplications. That should make my panel work on both older and future versions of Ctrlr I hope.
I have plans to make a panel for the Yamaha FB01, which will require a lot of bitwise operations, much more than the RefaceDX panel. I’ll wait starting that project until there is more clear about te future implementation of the bit library in Ctrlr’s Lua.
Hmm. It looks like the CtrlrLuaBigInteger stuff is something I could use to replace my failing bit operations since Ctrlr-5.4.x. But it worries me that I find the sourcecode in Source/Lua/Deprecated. What can I expect for the future? Should I rewrite the bit operations I use in my Lua code in Ctrlr *again* after some next release? There are too many (interesting!) panels banned to http://ctrlr.org/panels_deprecated already.
Should I wait? Maybe atom can give a comment?
use the CtrlrLuaBigInteger class for extracting/settings bits in numbers api/class_ctrlr_lua_big_integer.html
Dead link? 404 error.
I have to do more testing to find where and when crashes occur to be able to produce a more useful bugreport. I will keep my eyes open.
One thing I have noticed already: Could it be the lua bit library is not supported anymore? I remember reading something about that somewhere?
something like
bit.rshift(15, 2)works fine on my Ctrlr-5.3.201 (Linux 64 bits version from the website “Downloads” section) but crashes Ctrlr-5.4.16 immediately if used by a panel.
Tiny example attached, ctrlr-console window needs to be open to see what it does.Hint: in the SysEx Formula editor if you right-click in a byte field you will get a list of things you can choose from. This will automatically insert the correct code (for example ms or MS), if you make the right choice.
So if your parameter has a value range of 256 use ms and ls, if it has 16384 values use MS/LS.
Not quite true. The use of ms/ls or MS/LS does not (only) depend on the valuerange it has to be able to produce. More important is how the manufacturer has implemented this in the SysEx. Sometimes a manufacturer uses 4bits pairs without apparent reason, even if it can be done with single 7 bits values. Sometimes it’s the other way around. You always have to study the SysEx documentation carefully in all cases.
In other words:
ms/ls can have a range between 0 and 255, but so can MS/LS
MS/LS can have a range between 0 and 16383, but this doesn’t mean it really uses that rangeF0 42 30 0B 41 2E ls ms F7
I think this should be
F0 42 30 0B 41 2E LS MS F7lsis for 4-bits nibbles,LSfor 7-bits. xx=0~127 is a 7 bits value, but alsoMSshould be 7-bits in this case even if only values 0,1,2,3 are used.edit: hmmm… maybe
msalso works, I am not sure. ButMSdoes not hurt. I guess 🙂edit2: It must definetely be
LS MSwith capitals. I just tried. Hint: From the Ctrlr menu useTools->Midi Monitorand activateView->Show RAW dataandMonitor output. Then you can test your sliders and knobs and see what they are sending to your Korg DSS-1.Feature request: Maybe the Lua version is something that could be added in the Help->About dialog?
No big deal, but why not?
Yes, I found that one.
console(_VERSION)
currently gives me “Lua 5.1”
You can download and try my Reface DX panel now. Yesterday the site was down. Today the site was online again, but a bugfixed version was replaced with an older version. I have uploaded latest version with some minor bugfixes again. Sorry for the noise.
There is a bug here. Opening a panel with LUA disabled and saving the panel will delete all LUA methods, be careful.
I found your warning about this bug a few days *after* I had bumped into it myself. Ouch. This is a really ugly one.
Thank you!!!
Now it works, even on my Linux box! It was set to “true”, and I changed it to “false” in my Lua code.
Thinking about it … I will also try what happens if I don’t set that parameter. Maybe in that case it will default to the choice from the Ctrlr settings dialog?
OK, thanks. That helped me get going!
As you said, check each message size. From f0 to f7 is a single message. When the size match what you expect you got it, no worry about any other message. This method only process what you want, not every message received.
The problem is: I do worry about the other messages. If I send one dumprequest to my RefaceDX it responds by sending 7 sysex blocks. 5 of those blocks I actually need to read, 2 blocks I want to ignore, and 4 of those five have the same size. I need to check their content to know which is which.
It’s not quite clear to me how “Called when the panel receives a MIDI message” works internally. What happens with the data in the midibuffer after I have read them? How long will data stay there for reading?
What I want to do – but don’t know how:
1. Flush all the SysEx data in the buffer to get stable and reliable responses in step 2.
2. Send a dumprequest to my RefaceDX
3. Read all SysEx data, not only one SysEx block, that are received in the buffer. It looks like non-sysex bytes like 0xFE and 0xF8 are ignored automatically in Ctrlr. That’s good.
4. Check the received data for checksum errors or missing data
5. In case of errors start again from step 1, and keep trying maybe 3 or 4 times before showing an error or warning message.
6. Put all these data in one or more Memoryblocks so that I can do all kinds of things with themMaybe these are partly things that Ctrlr already handles automatically. But I am getting unreliable dump results with my current experiments. Sometimes it works, most of the time I am getting only part of the data received correctly.
PS: Panel parameter changes, loading and saving of SysEx dump of complete patch, sending SysEx dump, including checksum calculations, are now all fully functional. Much of the Lua code I wrote for this I can re-use for processing the received MIDI data. But I first have to get the correct and reliable SysEx data from my synth into Ctrlr.
