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…
1 Like
Search on “hallucination”! 
1 Like
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.
1 Like
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.
1 Like
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.
4 Likes
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.
3 Likes
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.
1 Like
Amazing project btw
1 Like
Thanks mate 
Fader sends (and receives) CC#48.
3 Likes
Helping people put midi hub to work since 2020
Isn’t the caveat that external audio cc has to be enabled? I guess that would be obvious, but I think I remember using ableton to send cross fader values to a mega break of doom and having that set to internal only and it wasn’t working.
It probably confused me initially because I assumed cc48 was associated with the midi cc and not the audio cc. Derp.
I misunderstood this too in my early days with the OT. As a concept I didn’t get what “audio CC’s” were, for me CC’s are midi by definition. That’s one of those clumsy misnaming issues… Once you get the idea that the midi sequencer and the audio sequencer are two totally independant entities that share the same protocol for external interaction (midi) it becomes a bit clearer but better naming of some functions and parameters would have avoided many a grey hair all over the planet.
I use many a scandinavian-engineered product in several domains, but they all seem to share this “Ikea-syndrome”: many convoluted ways to go to the same place, and new names for existing and well-established concepts that make the products look “deep”. They’re all fine, but often confusing.
1 Like
I wanted to do this thing with the MIDI arp and the fader…
but it didn’t work.
So +1 for cc and MIDI arp to be implemented in the scenes!
That would be awesome 
Think about the harmonic possibilities.
Audio and MIDI conpkerely in harmony with each other.
It’s discussed over and over on the forum: it seems that implementing scenes for Midi tracks would choke due to the huge amount of possible Midi cc’s you can have with scenes.
Still as already proposed, they could propose scenes with limited tracks/parameters to keep low the amount of midi data. At least, muting midi tracks would be more than necessary.
1 Like