Bit functions ot working

[darlock]

try to make bit extraction for panel

[code:2sf6kjpx]sn2ex1 = programdata1:getByte(289)
panel:getModulatorByName("FMNoise"):setModulatorValue(sn2ex1:getBitRangeAsInt(2,1), false, true, true)[/code:2sf6kjpx]

receive lua error: attempt to index global (a number value)

[atom]

that will not work you can’t call getBitRangeAsInt() on a integer, and the sn2ex1 variable is a simple integer value, it has not methods.

[darlock]

Can you provide example how to implement extracton of bit values from specific bytes of received sysex bulk?

[atom]

use the CtrlrLuaBigInteger class for extracting/settings bits in numbers api/class_ctrlr_lua_big_integer.html

[darlock]

It is not clear for me how i can use CtrlrLuaBigInteger class when i already extract some bytes from midi messages using getByte()
Can you write some example code?

[atom]

sure it’s really simple stuff
[code:1e1sj82q]
bi = CtrlrLuaBigInteger(3)
console (string.format ("bit 0=%d", bi:getBitRangeAsInt(0,1)))
bit 0=1
console (string.format ("bit 0=%d", bi:getBitRangeAsInt(2,1)))
bit 0=0
[/code:1e1sj82q]

[darlock]

Yea. All working now.

[m.tarenskeen]

atom wrote:

use the CtrlrLuaBigInteger class for extracting/settings bits in numbers api/class_ctrlr_lua_big_integer.html

Dead link? 404 error.

[Possemo]

I never saw a documentation too, but this is what I guessed out myself:

using CtrlLuaBigInteger on a variable (a number) will allow you to do bit operations on it, such as getBitRangeAsInt, and setBitRangeAsInt. I used this several times on my editors. Here for the calc of the simple checksum of the Matrix-1000 sysex patch dump:

-- calc checksum: addition of all bytes then mask by lower 7 bits

for chk=1,134 do
	sum=sum+PatchByteTab[chk]
end

sumBint  = CtrlrLuaBigInteger(sum)
Checksum = sumBint:getBitRangeAsInt(0,7)

• This reply was modified 7 years, 4 months ago by Possemo.

[Possemo]

another one, assembling a byte and putting the result in a table field:

-- assemble Nibble for Byte 53
byte53=CtrlrLuaBigInteger(0)
kbtrack=panel:getModulatorByName("VCF_KBTrack"):getValueMapped()
OSC2wav=panel:getModulatorByName("OSC2_Waveshape"):getValueMapped()

-- setBitRangeAsInt(0,2,0) -> (StartBit, how many bits, value in decimal)

if kbtrack ==  0 then byte53:setBitRangeAsInt(0,2,0)
elseif kbtrack ==  1 then byte53:setBitRangeAsInt(0,2,1)
elseif kbtrack ==  2 then byte53:setBitRangeAsInt(0,2,2)
end

if OSC2wav ==  0 then byte53:setBitRangeAsInt(2,2,0)
elseif OSC2wav ==  1 then byte53:setBitRangeAsInt(2,2,1)
elseif OSC2wav ==  2 then byte53:setBitRangeAsInt(2,2,2)
end

byte53Int=byte53:getBitRangeAsInt(0,8)
PatchTable[48]=string.format("%.2x", byte53Int)

I think you could do that like this:

-- assemble Nibble for Byte 53
byte53=CtrlrLuaBigInteger(0)
kbtrack=panel:getModulatorByName("VCF_KBTrack"):getValueMapped()
OSC2wav=panel:getModulatorByName("OSC2_Waveshape"):getValueMapped()

-- setBitRangeAsInt(0,2,0) -> (StartBit, how many bits, value in decimal)

byte53:setBitRangeAsInt(0,2,kbtrack)
byte53:setBitRangeAsInt(2,2,OSC2wav)

byte53Int=byte53:getBitRangeAsInt(0,8)
PatchTable[48]=string.format("%.2x", byte53Int)

• This reply was modified 7 years, 4 months ago by Possemo.
• This reply was modified 7 years, 4 months ago by Possemo.

[m.tarenskeen]

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?

[m.tarenskeen]

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.

[m.tarenskeen]

m.tarenskeen wrote:

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 … 🙁

[Possemo]

I’am hoping too that CtrlrLuaBigInteger won’t get trashed. Well for me, a short documentation of a substitute would be ok too. It seems like there are some non working features:

class_(“CtrlrLuaBigInteger”)
.def(constructor())
.def(“clear”, &CtrlrLuaBigInteger::clear)
.def(“clearBit”, &CtrlrLuaBigInteger::clearBit)
.def(“clearRange”, &CtrlrLuaBigInteger::clearRange)
.def(“setBit”, &CtrlrLuaBigInteger::setBit)
.def(“getBit”, &CtrlrLuaBigInteger::getBit)
.def(“setRange”, &CtrlrLuaBigInteger::setRange)
.def(“getBitRangeAsInt”, &CtrlrLuaBigInteger::getBitRangeAsInt)
.def(“setBitRangeAsInt”, &CtrlrLuaBigInteger::setBitRangeAsInt)
.def(“shiftBits”, &CtrlrLuaBigInteger::shiftBits)
.def(“toString”, &CtrlrLuaBigInteger::toString)

I think clearBit and getBit aren’t working, they just return a nil value. But this is no problem as you can do the same with getBitRangeAsInt and setBitRangeAsInt. setBit is working too, but could be substituted by setBitRangeAsInt as well. I never needed shiftBits and toString.

[pavel]

FB01 YES PLZ I LUV U

[m.tarenskeen]

pavel wrote:

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.

[m.tarenskeen]

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 anyway

bit_band = function(x, y)
    return x % (y + 1)
end

Using 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.

[atom]

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.

[m.tarenskeen]

atom wrote:

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.

[atom]

You should use BigInteger the native JUCE class, it’s bound to Lua, the CtrlrLuaBigInteger is an obsolete class that is there for compatibility puproses. The bit.* functions will remain it’s a low level implementation that is there for performance purposes

[Author]

Posts