|
|
Post by oortone on Dec 16, 2023 18:31:39 GMT
Hello, newbie here. This was quite a cryptic programming language.
Anyway, the manual says:
"Variables cannot be used in Stream Byter 1 rules"
But those Stream Byter 1 rules are never mentioned in any other place in the manual. So what are these?
I was trying to use a variable to set midi delay, like this (simplified)
ASS L$01 = $200
NX = XX +DL$01 +C
...but that does not "compile". So I guess I immediately stumbled accros a Stream Byter 1 Rule. So what do I do instead to be able to use variables instead of direct numerical values?
|
|
|
|
Post by redheronmusic on Dec 17, 2023 14:20:50 GMT
Stream Byter I starts on page 4 of the manual, with the title "Steam Byter 1 (MIDI Bridge version)"
These are the simple remapping rules. But no variables, etc., that comes in with ...
"Stream Byter II (MidiFire extensions)" at the bottom of page 6.
SB II is more like a programming language.
So NX = NN +DL$01 +C becomes
Edit - I always forget that MT requires the trailing zero, despite the manual stating: "first nibble of the first byte, with any channel removed." I need to highlight ([8-F]0) which is correct, showing the trailing zero.
If MT <= 90 # MT of 80 and 90 are the note messages
Snd M0 M1 M2 +DL$01 # equivalent to the clone message
End
|
|
|
|
Post by oortone on Dec 17, 2023 17:30:46 GMT
OK, thanks. Don't really get this concept. I realize it needs quite some time investment to understand. But now I have a starting point should I get the ime. :-)
|
|
|
|
Post by oortone on Dec 17, 2023 22:50:28 GMT
Stream Byter I starts on page 4 of the manual, with the title "Steam Byter 1 (MIDI Bridge version)" These are the simple remapping rules. But no variables, etc., that comes in with ... "Stream Byter II (MidiFire extensions)" at the bottom of page 6. SB II is more like a programming language. So NX = NN +DL$01 +C becomes Edit - I always forget that MT requires the trailing zero, despite the manual stating: "first nibble of the first byte, with any channel removed." I need to highlight ([8-F]0) which is correct, showing the trailing zero. If MT <= 90 # MT of 8 and 9 are the note messages Snd M0 M1 M2 +DL$01 # equivalent to the clone message End OK, had a closer look now. So MT is an incomming message and then somehow this is divided into M0, M1 and M2 which is sent out again, delayed. How did MT become M0, M1 and M2 and why can't I send MT out right away? I don't see an explanation of M0, M1, M2 in the Streambyter manual. I guess there' no language reference or anything? Is the manual all there is apart from this forum?
Also out of curiosity if there's polyphony and notes overlap (meaning there might be a new note on before previous message note off) how is this handled if you would like to do more advanced things. I mean there would be more than one MT (or M0, M1, M2 and so on) in that case how are they distinguished? Jut trying to understand the basic concepts here.  |
|
|
|
Post by redheronmusic on Dec 18, 2023 13:11:12 GMT
The manual assumes that you know something of MIDI.
When a single MIDI message is received, then StreamByter processes the message. SB is only working on that single message at any one time. It completes processing, sends out the message after processing, then waits for the next message. The variable arrays provide the memory necessary to carry information between messages.
Starting at the section of the manual that states:
we find:
Variables beginning with M refer to the current message.
- MT is the type of message. It is also the leading nibble of M0, the first character in the message.
- MC is the channel, also the trailing nibble of M0. (Caution - this could also be the 13th byte of the message - use M$12 or M0C for that 13th position instead)
- M0 is the first byte, M1 the second, etc
- ML Is the length
The M array gives you the handles to grab hold of the current message for processing.
A NOTE message has three bytes, the first is either 9_ (on) or 8_ (off)
the test
tells us we found a note message. (Message types are 8_ to F_)
We know that a note message is three bytes, so
sends out the three byte note message (i.e. cloned), delayed by the value in L01.
The original message is still in the M array and will be sent at the end of processing unless precluded by a BLOCK.
When the next message arrives, SB starts processing at the beginning, with the new message values in the M array & variables.
|
|
|
|
Post by oortone on Dec 30, 2023 17:53:23 GMT
OK, thanks that's helpful. Unfortunately I realize this programming language is for me since it's almost at "machine level". I see from other examples that one can use aliases to make it a bit easier but still...
Anyway, just one peculiarity that strikes me. Only Note messages can be interpreted as having "length" (the space between Note on and Note off). It's strange there's a length paramter. That's not in the midi specification. Also, does that mean this language can only process a midi note once it's "finished" (corresponding Note off received)?
|
|
|
|
Post by redheronmusic on Dec 31, 2023 14:32:57 GMT
Message length is the number of bytes in a MIDI message, not time elapsed between separate note on and note off messages.
Three byte MIDI messages (ML == 3)
Note On / Off
Control Change
Poly Aftertouch
Pitch Bend
Channel Mode
Two byte MIDI messages (ML == 2)
program change
channel aftertouch
Variable (ML == ??)
SysEx
There are a few other message types, less frequently encountered in SB work.
ML is only necessary when processing SysEx, as the other message lengths are fixed.
A summary of MIDI message formats is handy any time you are working with SB.
SB is processing a single message at any time, in the order the messages arrive.
|
|
