There is already a thinning behavior.
CC with same values are not sent consecutively. I couldn’t find it in the manual. @Open_Mike! Shame on me! 
Can be annoying if you want to send the same event consecutively. True for Pitchbend and Aftertouch IIRC.
Im talking something a bit more spontaneous
Yeah, I was just being daft 
I usually plock spontaneously! 
You can record in live rec to reduce data, and/or set lfos to hold with some trigless.
Eyes wide shut!
Goliath is still available, and pretty cheap.
@Open_Mike, seriously, could you find it for me? I need new glasses, and I could find the right terms with search…
When I first saw that I was going say but of course I have the manual memorized and post the clip…
Then I went thoroughly looking through the manual and couldn’t find it either… 
I thought it was in there, maybe we just figured it out by testing…
Search on “hallucination”! 
I thought you quoted it once…maybe you quoted yourself. I always wonder how to express it correctly…
That sounds reasonable, but if that is the only concern, restricting for example to only 10 cc’s in total and by discriminating theses 128 possible values to just 32 possible values (theses values are interpolated anyway), you would end up with a much lower number.
10 (cc’s) * 32 (possible values) * 4 (qrtr seconds) = 1280
I’m no midi expert, so I don’t know if this is big or small amount of midi messages per second.
I was unaware of this box. Very cool.
I think having this as a half implemented feature would be worse than not at all. Can’t you just sample input and fade that?
My compromise suggestion: make the cross fader cc# assignable. Then you’re not sending out too much Midi data, but those whose synths have macro/morph knobs or mod wheels can set them up at that end. Would be nice for some users, at least.
That’s way too much. Standard MIDI can transfer just 3125 bytes per second in total. A single CC message requires 2 bytes 3 bytes. So you would completely saturate the connection with CC messages from this one device only. Sending any MIDI message in time from another device would become impossible.
CC messages are 3 bytes each(1: type+channel, 2: control number, 3: control value).
Only follow-up messages for the same control type+channel can be shortened to 2 bytes.
So yeah, it would saturate a MIDI DIN connection.
Haven’t looked into it but it seems there is a small and manageable message that goes out saying, “the fader’s at this position,” which can be used in some setups.
Yeah, if you have midi going out from the Octatrack and then into some kind of midi host that can do a bit of scripting, then into your other midi device, rather than straight from the Octatrack to the midi device, you can totally do it.
Amazing project btw
Thanks mate 