I did some testing with my example file and noticed the following:
The CC envelope polling “only on new values” Taktik promised to 1.9 appears to function as advertised in first beta. Now my XV-5080’s MIDI message indicator actually blinks instead of being lit all the time depending on the envelope which means less strain. Now the synth is GENERALLY able to handle considerably higher amount of CC envelopes at time without choking. However, if the envelopes are steep, for example for fast filter sweeps, things are not as rosy: New CC values must be sent more frequently to synth versus less steep envelope. This eventually leads to choking and it does so suprisingly quickly.
At this point the adjustable polling frequency I suggested in the thread linked above would be beneficial. For instance, if I make CC 07 (Volume) value to change from 0 to 64 in four lines (speed 6), there are quite a many CCs per row sent and I’d like to get rid of some of them since I couldn’t hear the difference between 16 or 64 values in this fast volume transition anyway. I could imagine several ways to implement this:
The first way would be to intentionally skip every second/third/fourth/etc. CC send. However, this kind of approach in its simplest form would lead to choppy transitions if it’d be applied to less steep parts in the same envelope. The transition would be like 00-03-06-09-0C-0F-12-15-…
The second way would be to introduce an adjustment, which allows CCs only to be sent twice per tick, every tick, every second tick etc. or based to clock. However, this kind of approach would lead to quick transitions being choppy if user is unaware of the nature of the adjustment. The transition would be dependent on the steepness of the envelope.
The third way would be to introduce a more “intelligent” hybrid of these two previously mentioned ways: If the envelope has fast transition, the program should deliberately, depending on the steepness of the envelope, drop off some CCs, either tick- or clock-based just as described in first example. If the transitions becomes slower, the amount of dropped-off CCs would decrease and generally behave as in second example. If the transition is very slow, nothing needs to be dropped off.
Implementing something like this for CCs (whether and when) is up to you. I’d DEFINITELY love to see at least some kind of adjustment ASAP so I could use steep envelopes. At current, the CC behavior is without any doubt better than in 1.8.0 but now I’m completely unable to predict the amount of sustained envelopes by XV without factoring in the steepness of the envelopes.
Currently the update rate is limited to ticks, so its already now very choppy.
How do other 20 year old MIDI sequencers handle such things? Can not remember that you could set up update rates in Logic or Cubase.
Your “third way” would definitely work, but all this would be a hell of work. I am not sure if we should concentrate on this now…
If you can develop any sort of extra adjustment with ease, please include it in 1.9. I guess that any kind of adjustment that involves more work will be left for later versions since I believe it’s pretty much bughunt now.
Well, I can only speak for Cakewalk’s Sonar, since it’s one of the two other sequencers I own. The way Sonar handles automation is that if you move the mouse slower while drawing a curve, the density (amount) of the events will be higher, with the density level depending on the speed of the mouse movement. Moving the mouse quicker results in less dense curves - in other words, more thinned-out values.
Now, SONAR’s approach will not apply directly to Renoise, as Renoise’s automation is node-based rather than curve-based, but here’s a suggestion:
If you could build the feature into the automation to be able to select the curve between two nodes, then maybe you could have a “Density” text box underneath the automation window (where the Cut/Copy buttons etc. are located), measuring it in percentages. So, if a curve between two nodes was selected and the Density was set to 100%, all the CC values between the two nodes would be sent, with each value being sent at a timestamp that would be determined by the current interpolation setting. If the Density were 90%, only nine-tenths of the CC values would be sent, etc.
The added advantage of adding a feature that enables you to select the curve between two nodes (or maybe even use Shift-select to select more curves between more nodes) would be that we could then be able to select different interpolation methods for each bit of an automation curve, so for example, the curve between nodes 1 and 2 could be Linear interpolation, the curve between nodes 2 and 3 could be Cubic, etc. This would allow much greater freedom with regards to automating stuff in general.
shrug It was just a thought. I don’t know how well it would work though, I’m just brainstorming.
Ash
