Metro Object and SXFormat Object

my first thought was that you migth have forgotten to close with 247, but it seems to be present. :)

not sure where you are sending this? within ableton live it might be filtered out, and when you send it with 100 ms to a hardware this might be simply too fast for the receiving device.

i´ve always wished midiout would have an outlet for debugging that kind of stuff.

I see no problem with metro and changing numbers, but found another issue.
I tried with a counter instead of the number box. In my Midi Monitor the output is fluent with changes, the lines are shown as Roland 12 bytes. But Number 62 (hex 3E) produces garbage and also kills the next number (63, 3F). Then normal output continues (from hex 40 upwards). Looks as if number 62 sets the checksum to 00 and that does not work for some reason.

Hello,

Thanks to the both of you. It's going to a Roland JV2080. I'm not sending changes as fast as every 100 ms. Even sending a bang using metro every few seconds the change is not recognised. For some reason the bangs generated using metro are not recognised by the external machine at any speed. I will try with a counter and see what happens. I was hoping to be able to change values as the metro is running rather than having fixed values. Do you think the problem with numbers 62 and 63 is due to the fact that they're almost the halfway point of 127?

Thanks again

this is the problem

use blue side for correct checksum.

sxformat 240 65 16 106 18 3 0 / 16 / 47 / is $i1 / is (128-checksum(5,9,1)%128)%128 / 247
metro ???
no idea, should make no problem, but calc midi baud rate and
max speed .
for sysex slower - better

P.S:
did I not allready spend some time answering exactly same question to you :

https://cycling74.com/forums/sysex-arguments

Hello,

Yes, I've been trying to implement the advice you gave to me previously. I've employed it successfully in a number of different ways. But I've hit this behaviour with the metro and the sxformat object in conjunction with the Roland machine that hasn't happened in any of the other iterations where a metro isn't employed. With the corrected code I'm still having the same issue. It works with counter and gate.

Thanks

i wonder what happens when you use metro but turn overdrive OFF in audio preferences.

Hello,

Sorry, is that the same overdrive viewable in audio status? I've just tried it, but no luck.

Thanks

It can't be problem of metro object itself.
But, as first give a metro initial slow time argument,
to avioid overloading of JV midi buffer.
then - you can't compare midi output executed by metro, uzi etc
and gui executed messages.
That number will never send all values between 0 - 127
if you make such movement.
Capture the output and look inside.
Non GUI executed messages will not miss a single one.

And at the end, JV series of synths are NOT meant to be edited in real time
using sysex at all, only using dump messages to exchange patches
etc, and need slow sysex stream.

this is shot of manually moved 0 - 127, not to fast
and captured via IAC buss midi feedback on old Mac.
only 21 were sent...

if triggered by uzi all 128 messages were sent and received.

So my guess is that you are overloading JV midi input buffer
or that it simply can't react to fast sysex messages.