Is this possible in the Logic Pro environment?

[synthoid]

Hello people

I need the Logic Pro environment to translate my custom sysex message to a CC message and to determine to which environment midi device the CC should go. I don't know if it is possible, so I hope some can help.

My custom sysex message is as follows:

F0 01 00 07 VAL F7

01 = Synth id

00 = Synth channel

07 = CC number

VAL = CC value

The synth ID will determine to which environment midi device  the CC message needs to go.

The synth channel will determine to which channel the CC message needs to be sent.

CC number determines which midi CC the logic pro environment needs to create.

VAL determines which CC value needs to be created.

So basically I need all the bytes to be extracted from the custom sysex message, so I can compare them so the environment knows where I need to route and what CC message needs to be created.

I hope the CC message can be created generically.

Thank you in advance.

[des99]

The only byte that need to be extracted is the VAL byte, as the rest are known and are used to match the incoming message to the environment cabling etc you want to route it to.

But yes, it's possible to set this up in the environment using sysex faders and transformers etc.

You can't easily extract multiple different bytes out of a string, sysex faders are designed to pull out a single VAL (even if it's spread over multiple bytes), so you'll need to use the other bytes to match the various items you want to route around (ie one item responds to a message with a CC value of 1, another to 2, etc, down to however many you need).

There might be some hacks to workaround this (I can think of some, including duplicating the sysex fader but changing the position of the VAL byte) to extract different bytes from an incoming message, but it's been a while since I've hacked on sysex faders in the environment to remember all my old tricks.

Others may have some additional advice...

Edited March 6 by des99

[synthoid]

23 minutes ago, des99 said:

The only byte that need to be extracted is the VAL byte, as the rest are known and are used to match the incoming message to the environment cabling etc you want to route it to.

But yes, it's possible to set this up in the environment using sysex faders and transformers etc.

 

I hope I am not misinterpreting it, but doesn't that mean I need to have a fader for each sysex string? That is what I want to prevent. I want to get a generic solution.

What you say about copying sysex faders and shifting the VAL might be a solution to get a kind of generic solution. The question only remains how I get a generic CC, ie, that I don't need 128 transformers for 128 ccs and that per channel. Any idea how I can do that?

I will definitely try something and report back here what the results are.

Thank you, Des99

[des99]

2 minutes ago, synthoid said:

What you say about copying sysex faders and shifting the VAL might be a solution to get a kind of generic solution.

Yep rig up some simple test cases and see if you can get it to work for your needs, then go from there.

3 minutes ago, synthoid said:

The question only remains how I get a generic CC, ie, that I don't need 128 transformers for 128 ccs and that per channel. Any idea how I can do that?

I thought I answered that with the VAL suggestion? Or are you talking about on the output end? You'll have to bear in mind that working in the environment using "variables" is not like a programming language - it's always awkward and over-complex because the environment is a limited, "visual" kind of programming. To simulate variables, you generally use faders, so you'd extract the value you want from your sysex string and use that to remote control a fader with that value. You then use that fader value in constructing your final output CC accordingly.

[synthoid]

15 minutes ago, des99 said:

 

I thought I answered that with the VAL suggestion? Or are you talking about on the output end?

Yes, I was talking about the output end. I don't want to use 128 faders for 128 CCs if that is possible. So my question is how do I make the CC output generic, so 1 fader to cover 128 CC outputs.

[des99]

6 minutes ago, synthoid said:

So my question is how do I make the CC output generic, so 1 fader to cover 128 CC outputs.

As I said in the "or are you talking on the output end paragraph" above - extract the value, set a fader from that value, and use that for constructing your final output message, with your "variable" fader for CC, and your "variable" for VAL all making up your final message.

Like I say, rig up a small test case and figure out the routing and transforming you need, then once you've got that implemented, you can scale it up from there if necessary.

I'd say get into the environment and start hacking it up, then if you're struggling with something specific, we have a concrete example and specific situation to help with, rather than me building a general solution for you and laying out a step by step recipe.

Edited March 6 by des99

[synthoid]

13 minutes ago, des99 said:

As I said in the "or are you talking on the output end paragraph" above - extract the value, set a fader from that value, and use that for constructing your final output message, with your "variable" fader for CC, and your "variable" for VAL all making up your final message.

Like I say, rig up a small test case and figure out the routing and transforming you need, then once you've got that implemented, you can scale it up from there if necessary.

I'd say get into the environment and start hacking it up, then if you're struggling with something specific, we have a concrete example and specific situation to help with, rather than me building a general solution for you and laying out a step by step recipe.

Ah, I see what you mean now. That was what I didn't realize yet.

Yes, I will start hacking it up. I want this to work, so my environment works for me. I will be back as soon as I can fire up the machine. Thank you so far.

 

[synthoid]

Des99. I found out I don't have a complete grasp of the sysex fader yet. I am already stuck on the first step of what I want. I hope you can point me in the right direction.

To repeat my custom sysex message is:

 

F0 01 00 07 VAL F7

01 = Synth id

00 = Synth channel

07 = CC number

VAL = CC value

 

 

I did manage to filter incoming sysex messages with sysex faders. I generate 3 messages by my midi controller.

Virus channel 1: F0 00 00 07 VAL F7

Virus channel 2: F0 00 01 07 VAL F7

M-Base channel 1: F0 01 00 07 VAL F7

I connected the 3 faders to a monitor each. I can see that the sysex message arrives in the correct monitor. So at least those messages are routed correctly.

https://imgur.com/a/kaOMFHv

Virus channel 1 and 2 I hope to merge in the future but for now they can be filtered by separate sysex faders.

And now I am stuck. The VAL is the value of the CC. When I set that value in the next fader, how can I get my CC number? When I look at the shifting of VAL to the CC number position, what happens to the CC value?

And how does the transformer come into play here? I am willing to put in the work, but right now I have not a clear idea of what I am doing and how I arrive at extracting the CC number and the CC value. I read some environment help files, but they don't give me what I need. I can't link it together.

 

 

 

 

 

 

 

Edited March 7 by synthoid

[des99]

It would help to see the parameters of an example sysex fader so I can see how you've currently got it set to... is the fader value/position being currently updated with the VAL parameter? As you send your sysex string, you should see the fader move to the position of the VAL (ie, you've extracted that byte into the fader position), which you can then fader BANG to use that value elsewhere.

[synthoid]

59 minutes ago, des99 said:

It would help to see the parameters of an example sysex fader so I can see how you've currently got it set to... is the fader value/position being currently updated with the VAL parameter? As you send your sysex string, you should see the fader move to the position of the VAL (ie, you've extracted that byte into the fader position), which you can then fader BANG to use that value elsewhere.

The fader value/position is being updated with the VAL parameter, yes.

Here is an example sysex fader with the corresponding sysex expectation.

 

Edited March 7 by synthoid

[des99]

1 hour ago, synthoid said:

The fader value/position is being updated with the VAL parameter, yes.

Ok, great, so you've correctly pulled out that value from the incoming sysex string into the fader (which is your "variable" to hold this value).

As you're somewhat familiar with the environment, you should presumably know how to use that fader to output it's current value to further environment processing as necessary. (If not, look up fader bangs in the environment manual).

This is a somewhat fundamental feature for complicated environment processing (which would be so much simpler if you could do *actual* programming in the environment).

Edited March 7 by des99

[synthoid]

4 hours ago, des99 said:

Ok, great, so you've correctly pulled out that value from the incoming sysex string into the fader (which is your "variable" to hold this value).

As you're somewhat familiar with the environment, you should presumably know how to use that fader to output it's current value to further environment processing as necessary. (If not, look up fader bangs in the environment manual).

This is a somewhat fundamental feature for complicated environment processing (which would be so much simpler if you could do *actual* programming in the environment).

I looked up the fader bangs. I see I need Meta message 99 to bang the current value of a fader. I take it that is what you are pointing at. However, I am missing something, like when would I do a fader bang. Somehow this fader bang needs to be triggered then.

And there is something I try to figure out. You mentioned shifting of VAL to extract the bytes from my sysex message. But when I shift the val 1 position back, the previous val would never match with the incoming sysex. Do you have an example of how you would shift a VAL?

Maybe another solution is also possible. I see I can have my VAL be an MSB/LSB combo. Is there a way to transform that MSB/LSB combo to a CC nr/CC value combo? In that case I would only need to decipher those last 2 bytes in my custom sysex message. It is just a thought, even if still want to know how I could filter my bytes one by one so I can route to the device I need.

[polanoid]

14 hours ago, synthoid said:

Here is an example sysex fader with the corresponding sysex expectation.

Now you have set the fader to output a SysEx message as well. I guess you want it to output a CC message instead (in which case you'd need to set "Output" to "Control")?

[synthoid]

5 hours ago, polanoid said:

Now you have set the fader to output a SysEx message as well. I guess you want it to output a CC message instead (in which case you'd need to set "Output" to "Control")?

Here is what I want. When my custom sysex arrives it will count 4 bytes not counting F0 and F7.

The first byte will identify which synth I want to send a CC message to.

The second byte will identify which channel of that synth should receive the message.

The third byte will determine the CC number, for example CC 7 for volume.

The fourth byte will determine the CC value, ie how loud the volume is.

My wish is that all bytes are generic. So that when I send a message from my controller I don't need to have a fader for every message. I need a fader for all messages. A fader that will route my data to the correct synth. Say, I have 16 messages (will be more) in my midi controller. Then those messages need to arrive at the main fader. The main fader will then lead it to the rest of my synths through a structire that I am trying to figure out. That is why I need extraction of the bytes.

The second best option would be if I can have the last 2 bytes of my sysex message in a MSB/LSB VAL that I can transform to a CC message. So MSB will be the CC number and LSB will be the CC value. in that way it doesn't matter which combo MSB/LSB it is, the fader filtering my sysex message won't have to be repeated 128 times for every CC message. I need the CC message to be created generically.

[des99]

Yes, but as explained you can't extract multiple bytes out of a single message with one sysex fader, so you have to do it piecemeal, with different faders extracting different bytes, and then do a bunch of stuff to ultimately combine them and output the combined message as required.

Now this stuff is a piece of cake in a programming language, or a dedicated sysex tool, but in Logic's environment, it's clunky, awkward and requires a bunch of weird things like using faders as "variables" and to handle logic decisions etc. This is a standard thing about this level of environment hacking - and there's plenty of environment threads in this forum going back years that are worth searching around for to gain an understanding of these tricks, if you've not used the environment like this before. It's not straightforward, and probably not intuitive, and will require some work to investigate and implement.

As I said above, it's been some years (maybe 20?) since I was doing this level of environment hackerey, so off the top of my head without refreshing my memory, I can't give you a direct recipe to solve and implement your problem. In order to tell you exactly what to do, I would have to basically sit down and solve and implement your problem to tell you exactly how to rig it up and have it all working nicely - and I have my own work to do, let alone the work of others. 😉

So the best I can do, off the top of my head, is give you some pointers in the right direction.

22 hours ago, synthoid said:

You mentioned shifting of VAL to extract the bytes from my sysex message. But when I shift the val 1 position back, the previous val would never match with the incoming sysex.

I think you are missing some fundamental concepts of what I was trying to explain. A sysex message comes in, and you need to have multiple faders all receiving to that message, one set with a VAL position of 5 (or whatever) to extract that byte into the fader, another one set with a VAL position of 6 to extract the next byte into it's own fader etc, so you end up with "variables" (faders) with the various data you need. Each fader is extracting one piece of data. You can then use your environment wiring and process to decide what to with those variables, and recombine the data into ultimately a final MIDI output string (or whatever) in the format you want.

What you are trying to implement, while it may sound simple, isn't trivial to do with the environment, particularly if you've not done this level of environment hackery before. It will take some learning and some time to understand, which is why I suggested starting with very simple cases to figure out the mechanics and the pieces, and build up from there.

Think along the lines of a sysex message comes in, it gets processed by a bunch of sysex faders that each output intermediate messages, which then get acted upon/routed/processed and combined generically to create the final output message you want based on the incoming messages to the destination.

There aren't that many of the hardcore environment hackers left on the forum these days, but there are a few, and hopefully these people will be able to help out along the way...

Edited March 8 by des99

[synthoid]

Des99. Your help is much appreciated and I understand you don't have the time rig something up for me. I managed to filter out all the 4 bytes to their respective faders now. If you could just give me pointers on how to recombine them into a midi CC message, then I can research that further, because right now  I don't know which search terms to use in this forum for environment examples.  You already talked about fader bangs, but which other components do I need to recombine my "variables" into a final midi message. And if the final message is a fader that outputs the correct CC how do I change the midi channel and CC number generically?

Edited March 9 by synthoid