Issue with gpio/in/analog & midi/out/cc & midi/out/clock

#1

Hello :slight_smile:

I am this morning experimenting with external clock and at the same time use the modular thing add on board to control some things. But I am experiencing some odd behaviour when using the midi/out/clock, midi/out/cc and the gpio/in/analog in same patch. Like this:

clock weird.png900x573 42 KB

I know this sounds really weird.. But when I connect the gpio/in/analog to the midi/out/cc in the patch... Axolotis clock about drops to half tempo...... + it starts to sound very very bad and super digital. As soon as i disconnect it, it sounds good again and tempo is normal again

Could anyone try this patch and see if you get the same result? I am thinking it might be my modular thing add on board that is not the best solder job. But I didnt really think it could cause these kinds of issue.

Tempo weird.axp (5.1 KB)

#2

Hey Jaffa tested your patch, has the same issues, tempo drop and digital harshness! Very weird!

#3

Also If you change midi/out/cc from din to other output... din related?

#4

@Blindsmyth

Thanks for trying it out. I cant find any logical explanation for this.

@keyman

Just tried changing to USB port. It doesnt happen there., so it might be related to the din only. Weird thing is when I disconnect the gpio/in/analog, but still keeps it in the patch, it doesnt happen. Reconnect it again to the midi cc out, it will happen again.

Anyway I think @thetechnobear and @johannes opinions would be nice on this.

#5

changing logic change by change speedlim seems to solve it. propably the jitter of the gpio was to much for axoloti's midi engine.

#6

Just tried that and it WORKS... Super :slight_smile:

Anyway, I still think it is a bit strange that a gpio with jitter can affect the whole system to sound "broken! and cause the midi dclock to become unstable

#7

Id need to double check, but I suspect, the midi din output is not threaded (unlike USB device midi which is)... this means the IO is being done in the audio thread, which is a bad idea as will lead to audio breakups, if you push it too much.

watching the amount of midi messages goes out is always a good idea, even with the threading of usb midi, this would 'break' since it has a limited ring buffer, which will overflow if too many messages are sent.

the real cause, as you have seen, is analog input will have jitter, how much depends on many things, but its pretty common to be use a filter to smooth it out.

in your scenario, id have probably converted the gpio to an int in range 0...127. then used change on that, since you only need to trig a CC when the resulting cc value changes NOT the float (which is much more accurate)... this is generally true of change, quantise first, then use change.
you'll probably still need to filter (or similar) though, since if you get the pot in just the right place, it could jitter around a threshold value, but obviously is much less likely.

#8

blindsmyth suggestion did work, using change speedlim . I put it in a controller object and have it live in every patch and for now it doesnt seem to affect anything.......

Will definatly try the scaling to 0-127.. I dont rememebr right now if it is midi/in or midi/out that has an integer version. Ill check up on that.

#9

of course it works... it just limits sending CC messages to the time you specify.
the issue is, because the float value is constantly changing, it will still be sending a stream of CC messages, even though the cc value is not altered.
e.g. imagine you set the throttle time to 1 second, and that the gpio is jittering around, 0.4999005 and 0.500005.
what will happen is you will be sending CC of value 64 every second, because the float value is jittering around 0.5, not enough to kill the system, but still a waste of resources/io

now if you quantise to 128, ( using a simple shift followed by a bit mask) , the result will constantly be 64 - so the change never triggers, as the (quantised) value has not altered. so no CC are sent saving cpu and io.

it doesn't actually matter if midi/out/cc supports integer of not! you can use your calculation for the trig condition... regardless of what is sent to the value.
that is why the trig is separate it allows the patcher to decide on the criteria of when to send updates - as there are a number of potential strategies depending on what is required.

anyway, this is why when working with midi, id always recommend monitoring the input/output when testing , either internally on Axoloti (midi/utils/monitor) or even better using a monitor app.

tip: if you have 2 Axoloti you can use one as a midi monitoring device ... use my thru object, and put the test axo in between patch tested, and device... if the midi light blinks like fury, or when you don't expect, then you know you have to take a closer look at the messages sent