Forum Replies Created
-
Posts
-
I hear ya,
I am starting a fulltime course for network/system admin tomorrow + a 2 year old on my hands at home, which is lots of fun but very intense. But after the course i will at least get a shot at a decent job- byebye underpayed boring jobs in construction ( was electrician for a long time, long days are standard there too…) 🙂
Best of luck in your new job!
Thanks for the insight Atom, and the ultra fast help !
I will try this out as soon as i have time to sit down for a little while again, today is my last day off and busy days a comin’
Once i crack this all that is left is creating a more beautiful gui and lots of copy pasting 🙂
Yes, these are all valid sysex strings, starting with a 7 byte header (not counting f0) and ending with f7 and can dump the messages to the console.
Appending to a memoryblock works, but the block is re-initialised every time a message comes in (of course), this is where i’m stuck.It would be awesome if i got this to work, because now i am getting values for individual parameters & it is getting a bit “messy” sometimes.
Whilst on the topic of dumps, anyone here has experience with parsing variable lenght dump strings?
The Emu Eos does a dump using a header,and then for each of the types of data it sends a “counter” byte stating the number of bytes that will follow for that data type. Once these are passed the next byte is again a “counter” byte, and so on & on, in one giant stream of data.
It has a ack/nack/hold system though so it is possible to break it up into several pieces using some timer system i guess…To give you an idea, a fully maxed out preset would be 1,772,606 Bytes – but it is advised to keep then under 64k 😆
Until now i have used individual request/response messages using timers to spread out the load, but even with only 1/4th of the total number of parameters in place it is getting a bit messy imo to keep it this way.
It will stay around for a while i, found out about this recently:
http://www.synthtopia.com/content/2013/01/20/midi-manufacturers-testing-new-high-definition-midi-protocol/Héhé, the c64. Mine had a floppy drive the size of a shoebox and loading took aaaages. Faster than the tape though 🙂
Makes me wonder if it still is somewhere @ my parents place, gotta check it out.Just wanted to add that the code in my v1.2 panel is indeed not so clean, this was made with my first experiences of using Ctrlr & getting the hang of the whole Lua thing.
In the mean time im have learned alot more and although there are many things i still need to learn it is much cleaner already. Try looking at the latest one i posted, there are some parts that still need cleaning up but its getting there 😉@ das,
Thanks for pointing out the difference in behaviour in both methods, i was not aware of this.
Thank you das, this was indeed the problem. After numbering the un-exported modulators with values higher than the number of exported parameters the problem was fixed 🙂
@ Zeoka,
If you use setValue you need only one bool value.
Like this:
panel:getModulatorByName("modulator-1"):setValue(yourValueHere, true)
It seems something is causing trouble for some people with the panels after uploading to the Ctrlr site as attachment :smashed:
If you don’t already use dropbox and decide to make an account please consider doing so by using this link, i get extra free storage this way.
http://db.tt/O2hnwRZDPS: You do not need to create a dropbox account to be able to download the files, these are freely available.
Fresh version!
Many under the hood changes.
All parameters now available in host
Moved keyzones parameters to tuning tab, made more sense to put them there imo.
Sample selection now working with minor bug; sample name and number are not always updated correctly when changing voices, stepping up/down the samplezones fixes this. Working on fix but may take a while.
Amp envelope layout changed, envelope graphics on top and bigger.
Multimode channel and preset select.MidiMessageReceived:getMidiMessage() does not exist, that is why you get the error.
Also the fx1 string has no use here, my guess is that this is the string you want to receive and then use some of the values of that string?The rest of it makes sense, you’ll get there in no time. A few months ago i knew nothing about programming, now i am starting to understand more & more also 😉
Here’s a little example of what script in the “called when the panel receives a midi message could be like:
panelMidiReceived = function(midi)
ID = midi:getLuaData():getByte(7)
LS = midi:getLuaData():getByte(9)
MS = midi:getLuaData():getByte(10)if ID == 1 then
if MS == 0 then
panel:getModulatorByName("modulator-1"):setModulatorValue(LS, true, false, true)
elseif MS == 1 then
panel:getModulatorByName("modulator-1"):setModulatorValue(LS+10, true, false, true)
end
endif ID == 2 then
panel:getModulatorByName("modulator-2"):setModulatorValue(LS, true, false, true)
end...
end
If i try this in saveToFile
mb=MemoryBlock()
mb:append(data) -- getrange result passed as parameter
<\code>It gives an error. Same if i try mb:insert(mb,data)
Got it working, thanks guys 🙂
I was declaring the memoryblock in the script that holds the values to be saved, and tried to pass it as an argument to saveToFile instead of making it in the saveToFile script itself.
I did have to do a little trickery to get it working as it looks like passing userdata as argument for a function is not possible.I want to save the result of a midi:getRange() but if i try i get errors. Worked around by making it a table and then it works as expected.
Now it looks like this:
originating script:
l = midi:getSize()if l == 255 then --programdump
-- make table from midimessage
t = {}
for i =1, l-1 do -- -1 remove header
byte = midi:getLuaData():getByte(i)
table.insert(t,i,byte)
endsaveToFile(t)
endIn saveToFile:
function saveToFile(data)mb = MemoryBlock()
mb:createFromTable(data)
file = utils.saveFileWindow ("Save file", File("test"), "*.emu", true)if not file:hasFileExtension(String ("emu")) then
-- this is stupid the File() should not be necessary but luabind does not handle type conversions wellfile = File (file:withFileExtension(String ("emu")))
endif file:hasWriteAccess() then
-- We can write to that location
file:replaceWithData(mb)
end
endThanks guys, gonna try it later today when my son is taking his nap 🙂
Will update with results.lol i just noticed 🙂
But i am having trouble with it, i cannot seem to be bale to save the contents of a memoryblock, if it try i get “no matching overload found”
Example:
In a script:
data = somevalue
mb = CtrlrLuaMemoryBlock
mb:append(data)
saveToFile(mb)
in the saveToFile script:
function saveToFile(dataToSave)-- By default the dialog window will ask for confirmation on overwrites, so we don't need to check
-- You can replace the File("").getSpecialLocation(File.userDesktopDirectory) with some other file location
-- that can be remembered across calls so that you hint the user his last browsed dir or some other location--x = string.format(dataToSave)
file = utils.saveFileWindow ("Save file", File(""), "*.emu", true)
if not file:hasFileExtension(String ("emu")) then
-- this is stupid the File() should not be necessary but luabind does not handle type conversions wellfile = File (file:withFileExtension(String ("emu")))
endif file:hasWriteAccess() then
-- We can write to that locationfile:replaceWithData(mb)
end
debug (what(file))
end
If i do not use a memoryblock and save the data as textstring it works…
idx0==midi:getLuaData():getByte(7)
is wrong, you are trying to compare values by typing ==
Assigning is done with a single =
idx0 = midi:getLuaData():getByte(7)ps best to ask questions like this in the programming part of the forum 😉
I had the same problem, TK posted a way to handle this
http://ctrlr.org/forums/topic/lua-sends-out-all-midimessages-panel-loaded-state-possible-to-disable-1194/hereYou mean listening for incoming midi and make stuff happen?
In the panel’s properties there is a “Called when panel receives a MIDI message”, the script you put there can listen to incoming data.
panelMidiReceived = function(midi)–grab the data you’re interested in
–in bytes
ID = midi:getLuaData():getByte(1)
LS = midi:getLuaData():getByte(2)
MS = midi:getLuaData():getByte(3)
— or as a range
string = midi:getLuaData():getRange(1,10)— then do stuff with it
if ID == 1 then
if MS == 0 then
panel:getModulatorByName(“modulator-1”):setValue(0, true, false, true)elseifif MS == 1 then
panel:getModulatorByName(“modulator-1”):setValue(1, true, false, true)…
end
if ID == 2 then
if MS == 0 then
panel:getModulatorByName(“modulator-2”):setValue(0, true, false, true)elseif MS == 1 then
panel:getModulatorByName(“modulator-2”):setValue(1, true, false, true)…
end
…
end
Mosrob,
The sample selection is indeed not working yet, the display only serves as an info object at this moment, showing the names of the samples loaded in the ram memory. Actual sample assignment to a voice has yet to be implemented.
About the envelope(s), you are the second person pointing out this nested approach is not ideal, i will change it around for the next revision.
Thanks for trying it out!
Cheerz,
HMidi feedback bug eliminated, fixed panel attached 🙂
Also made a little demo video @ http://www.youtube.com/watch?v=biG7Yd9SmlE&feature=youtu.be
