[EnzoF04]

goodweather wrote:

Can you post the link to the S700 midi implementation so I can have a look?

here it is in a OneDrive:

https://1drv.ms/u/s!As8Bha-GZclYhjnnkDId3SxjgHGZ?e=eQdcCp

goodweather wrote:

If there is some pattern in the exchange then it can be coded easily like:
– button to request load. Initialize MB. counter=0
– MidiMessageReceived: check received message, if byte(1)=0x40 then append to MB; send ACK; counter =1
else if size=60 then append to MB, send ACK; counter = counter+1
else if byte(0)=0xF7 then append to MB; display MB or do whatever with the data

You make me enthusiastic and motivated in picking it up in the near future! 🙂 Will need help though.

[EnzoF04]

hopefully this works

Attachments:

You must be logged in to view attached files.

[EnzoF04]

samoht wrote:

The communication stays open until the ACK is sent out responding to the EOD.

This is not the case; Akai terminates communication within tenths of seconds if ACK not received. This is very time critical. But as I read, there are coming good ideas to work.

samoht wrote:

This message can be recognized when you know the exact length of this message and/or the exact location of 45H in this message.

You mean in the complete sysex (all chunks of data messages) or in this specific chunk? Everything can be calculated from the message CTRLR can receive when asked for sample information, as I can remember.

So prior request for a sample, CTRLR needs to ask what the sample consists of (how many words, sample rate, sample length, sample parameters). Akai works with checksums and the received sample parameters make receiving sample data very predictable. (But my programming qualities lack knowledge.)

I’m very excited you’ve picked this up Thomas @samoht, @Goodweather and @Symphonicsamples
I still believe in success in this project.

[EnzoF04]

samoht wrote:

it is the handshake transfer procedure

I am aware of this, yes and I’ve got the documentation on the sysex implementation of the S700 (and S612) so I know how to communicate. But the problem is that CTRLR is forwarding the sysex after the closing byte is received. CTRLR does not allow to establish and maintain the ‘open communication’. (As far as I know).

[EnzoF04]

Yes GoodWeather, this is what I did. With the timer you mentioned. This was a really bumpy road to go. The timing is not accurate. So the change of ending or breaking up transmit before all data blocks are sent is pretty big. All can be checked because the size of the data requested can be requested from the sampler. All midi data blocks have their own checksum which can be calculated so everything is verifiable. But first I need to process the sysex while it is incoming (real time) and respond to this with appropriate messages.

I don’t have the time to dive into this at this moment but will plan to pick it up when decent ideas about processing the real time sysex are clear to me. Any ideas are welcome.

[EnzoF04]

Hi SymphonicSamples,

Well I’ve done some things with CTRLR for a SixTrak synth. But besides that, this is still at the same point. The problem is that I am not able to respond back to the sampler while sampler is sending sysex. As far as I know (been told) is that CTRLR is storing incoming sysex data and passes it on to next code and routines when CTRLR thinks it is complete or the synth / sampler has finished sending. BUT the early Akai samplers want receiving equippement to respond during the sending of their messages as: sending part A, expecting a receive part A OK, sending part B, expecting an receive part B OK, sending part C, expecting a receive part C OK and so on.

But if the Akai is not receiving this receive part A OK message back, it terminates the sending of the data.

So if someone can help me with this, it would be a good push into the right direction.

[EnzoF04]

Possemo wrote:

Here is the way you should do this upload

Dear @goodweather, this is not working for now. Can we think of a way to evaluate the (amount of) incoming bytes in real time? When I don’t send an ACK message to the S700, the S700 terminates with a f7 (EOX). So waiting with ‘midi message received’ is not they way to go. Randomly shooting ACK messages is not a decent way. I’ve seen the ‘ignore realtime MIDI messages on input’. Would this be an option? Tried to enable but no difference.

This is what you suggested a few years ago:

if myMessage:getSize() == 19 then
	mbHeader = myMessage:getData()
	iNumBlocks = mbHeader:getByte(9) + 128*mbHeader:getByte(10)  + 16384*mbHeader:getByte(11) 
	mbTemp=MemoryBlock()  -- will hold the sample data
	iCounter = 0
	-- send ACK
elseif myMessage:getSize() == 60 then
	iCounter = iCounter + 1
	mbTemp:append(myMessage:getData():getRange(1,120))  -- append block of 120 bytes
	-- send ACK
elseif myMessage:getSize() == 1 then
	if myMessage:getData():getByte(0) = 0xF7 then
	-- you can check iCounter vs iNumBlocks
	-- send ACK? Don't know if this is needed
	-- here you call a method that will load your data into the modulators
	LoadSampleData(mbTemp)
	end
end

I’ve attached my version as it is. Hopefully I can get progress.

Attachments:

You must be logged in to view attached files.

[EnzoF04]

Okay my reply was deleted by the forum: NEVER edit your post! (keep that in mind!)

I could use the back button to get my writing back. Here it is.

Sorry for the delay. Here is the very simple panel.

The stuff that is happening in the method (found in the Lua editor) are for you the most important. Make sure the panel is in ‘panel’ mode and not in ‘edit’ mode. See what is happening with values and see the comments I’ve wrote in in the Lua editor. The method you should look into is ‘rotary_OnChange”. This method is called when modulator-1 is changed. See the panel in edit mode. Select the modulator (modulator-1) and scroll down in the right side of the screen to where it says ‘called when the modulator value is changed).

Hope this gives you a start in thinking how to deal with the stuff you want to do.
Secondly you should dive into the syntax of Lua and conversion from decimal (base 10) to hexadecimal (base 16) and perhaps binary (base 2).

You also need to know what the minimum and maximum values that are accepted by the PCM. You need to know this because you have to make the correct midi messages that will be send to your device.

Hope this helps. Questions? Just ask!

Attachments:

You must be logged in to view attached files.

[EnzoF04]

First off: do you know the minimum value and the maximum value of the parameter in the Lexicon that you want to change with the panel? I assume this is a pretty big number because it is communicated over 4 bytes. 1 midi byte can have a value between 0 and 127 in decimal, in binary that is 00000000 min and 01111111 max.

Usually you can use components on your panel, the modulators to generate values. When you adjust a modulator on a panel, code that you programmed in methods, is executed and in this code midi messages can be send. Midi messages can be send very quickly after each other. So for example in a second you can sent 20 or more midi messages. You can thus change parameters in your equipment at real time speed. There fore you need to change the midi messages very quick. Here do the ‘x’es come in. The ‘x’es’ in your midi message are like placeholders, positions reserved for values and the values in these positions need to be taken from some where or given to the spots.

First step is you create a modulator on a panel like a uiSlider. The slider gets a minimum value of 0 and a maximum value of 127. (you can do this in the panel edit mode. Then in the right side of your screen, you can change properties of the uiSlider. Scroll down and put the min and max values in.

Also in the right properties side of the Ctrlr interface there is a field that says ‘called when modulator value changes’. You create a method there that is called every time the user changes the value of that slider.

In the code you are filling in of the ‘x’es’ in your midi message that is to be send.

I’ll demonstrate it in a panel but will do that later. Hang on this post, will update tonight.

[EnzoF04]

So the data for the parameter is send on bytes 07 to 10 to the Lexion, 4 bytes. It says On but you need not read on like switched on, you need to see this as decimal 0 n n or hexadecimal 0 x n n or binary 0 n n n n n n n.

The data is at the positions where it says ‘n’. That is the data part.

The data bytes can each contain a value between decimal 000 (binary 0 0 0 0 0 0 0 0) and 127 (binary 0 1 1 1 1 1 1 1). Byte 10, the 4th byte in the data part to be sent is the most significant one.

Can you grab the sysex the PCM is sending out? Like record it in a program? Can use the midi monitor in Ctrlr. Take a note of the values you are selecting when turning the knob. You should record 11 bytes of sysex every time you turn a knob. You need to select the automation mode and change values, not parameters, as the bottom line of your snippet from the manual says.
When you are capable of doing a recording of sent sysex from the Lexicon, you could start by recording the sysex for changing from data / parameter value 3 to 0 and store these 4 messages and record changes from max value -4 to max value.

Hope this helps

• This reply was modified 4 years, 1 month ago by EnzoF04.

[EnzoF04]

Here is a new BETA for the Six-trak, please be hard on me. I have to learn a lot still.

Big shout to @Dnaldoog, he’s been helping me A LOT! Thanks! And the forum members also!

See attached. It should be an improvement.

Attachments:

You must be logged in to view attached files.

[EnzoF04]

Thanks for the clarification! This helps! (again)

[EnzoF04]

Tedjuh wrote:

https://www.tutorialspoint.com/lua/lua_functions.htm

Interesting, thanks for pointing me in the right direction, Tedjuh! (Y)

[EnzoF04]

I have it, problem is the difference between the method. Thanks for the replies.

What is the difference between:

midiOn = function(--[[ CtrlrModulator --]] mod, --[[ number --]] value, --[[ number --]] source)

and
function doSomething()
and
Thanks for clearing out!

[EnzoF04]

Very useful, Goodweather! I know my coding is Fred Flintstonian and I have to improve but doing it this way I get accustomed to declaration of data and variables and altering those. Last week I made a method myself with three variables and that worked. Have to learn how to give a processed variable back to the code that was executing the method. But I’m getting a bit more of a grip. Lua is fun to code. I will start the improvements to achieve a more stable panel.

Thanks for the advice, it’s much appreciated!

[EnzoF04]

Will try it tonight! Keep you posted!

Thanks, Tedjuh!

[EnzoF04]

Thanks Tedjuh, That would be a nice work around. Can explore the SCI-id sending receiving. Would love to, from the user interface psychology stand point, to implement a midi on/of. This will give me the future possibility to implement different midi modes, so I can assign a single voice to program (patch) and other modes.

The work around with the triple position parameter is a nice concept, thanks! The bigger challenge is to get the data analyzed from a table. It’s declared as:

modulators{
parameter01 - value 02
parameter02 - value 01
parameter03 - value 00
parameter04 - value 63
}

I have to evaluate the values of parameter02 and parameter03. Thinking about questioning this gives me a rough idea of how to do it. Will try it when there is time!

Thanks for now, Tedjuh!

[EnzoF04]

human fly wrote:

btw, am thinking of re-doing mfb synth liteII panel and a panel for the mfb polylite. which might be similar in a way to sixtrak, if that can do a poly mode, or 6x mono mode. things like defining a global midi channel, and the individual channels. have not really attacked it yet, just preliminaries.

With the Six-trak such a thing is possible but documentation is really by some Fred Flintstone… (bad documented) You can check my work how I do it. Have to get the Six-trak panel a little more stable..

[EnzoF04]

Hi Goodweather,

Thanks for the clarification! My midi patch bay is ‘ill’, don’t like to process a lot of messages in a short period of time. 🙁

Yes, I understand what you mean by making code more efficient. The last week was a really good week for me, Lua and Ctrlr! Got some placebo panel with a function with 2/3 variables and a ‘for… do’ loop running. This is fun and compacting things; preventing copy=pasting and coding same and changing an individual value. I’m testing now and getting small things to be corrected. Hope to release the panel as a final beta this week. Dnaldoog helped me also as did you and Human Fly and others, sharing code and work around in the forum.

Next up is a ‘random patch generator’ and I want to explore the stack mode of the Six-track which you can assign a program to one voice, making a six program voice.

It’s real fun!!

[EnzoF04]

goodweather wrote:

Question1: do you remember what you changed the last time you used it?

Yes, you figured it out nicely, copying and pasting function, doubling a function name.

goodweather wrote:

Question2: do you have your last working version?

I only save over a previously saved file, have to change that workflow!

A question: is it possible to damage the midi input on a synthesizer when over loading the synth input with data? My Six-trak isn’t responding to any incoming midi any more after the crash. Ctrlr gave me some midi hw error. I didn’t change setup or anything. Really strange.

And another strange thing: When I press a key on the synth, Ctrlr app crashes.

Solved: Had to reset (restart) the Akai ME30p II midi patch bay… (relieved massively) sorry to bother!

• This reply was modified 4 years, 1 month ago by EnzoF04.
• This reply was modified 4 years, 1 month ago by EnzoF04.

[Author]

Posts