Peavey StudioMix Bi-Directional Control Via OSC

[Banned]

Another revision is up for testing, v0.8.

In this version, I have added a timer mechanism in an attempt to prevent undesirable feedback from the StudioMix faders. The mechanism works as follows: if a MIDI message is received from the device, and is within the specified time interval of an OSC message from REAPER targeting the same fader, that MIDI message is *not* converted to OSC and sent to REAPER.

You can set the time interval using this value:

fader_feedback_interrupt_time = 0.1; // in seconds (0 = OFF)

Hope this helps, curious if it actually does. Maybe try a relatively high value, like 2 seconds or so... not sure how long the device needs before the faders completely stop moving after a change (or how long you guys need to move your hand from the mouse to the controller... ).

(Another idea: only convert MIDI from faders to OSC if the last X MIDI values from the device were targeting the same fader.)

Oh, and I fixed some of the logging stuff that got broken while fixing the pan issue. Will check and clean up the logging a bit more later, since you guys seem to like it.

[N2NPro]

Hi Banned et al,
Ok I re-tested at these settings:
Fader Cal: max 15871, min 0
Fader Re-Scale: max 0.716, min 0 *note(0.002514 = -127db)
*these settings = inf-0db on SM and Reaper on all Faders as long as Jitter Eater is either off or stays below 70. 80 = -107.1db-0.15db. Meaning, when moving the SM fader it will only reach from -107.1db to -0.15
Dead Zone; tested between 0-8000. No noticeable difference at any setting.

The Jitter Eater range seems to be happy about 30-70 before losing range.
It does eat some jitter but does not cure it.
How to test Jitter:
Insert 32 tracks = no jitter
select all move SM fader and release = 3-5 seconds post fader move jitter then stops. Move the fader again, same thing.
*note: with Jitter Eater off, jitter continues more than 3-5 seconds and will sometimes not stop (thus my workaround kill switch).

switching banks either via mouse or SM produces jitter/creep for 3-5 seconds ranging upto several db (no good).

Aux Knobs no longer function... I will take a look at it.

The Pan goes hard right when feedback is happening and you try and turn a pan knob. When feedback is not happening, pan works great all tracks.

I tried your Solo/Mute code and 6,7,14 don't work for me. The only way I have found is by using custom actions to give a new Cmd ID. The new Cmd ID works...

So far v07 settings tested are best at:
Fader Cal: ON, max 15871, min 0
Fader re-scale: ON, max 0.716, min 0.0
Jitter Eater: ON, JitterDelta 70
Dead Zone: OFF

jico27, let me know your results...

Thank again Banned!!!

N2N

[Banned]

Originally Posted by N2NPro

Hi Banned et al,
Ok I re-tested at these settings:
Fader Cal: max 15871, min 0
Fader Re-Scale: max 0.716, min 0 *note(0.002514 = -127db)
*these settings = inf-0db on SM and Reaper on all Faders as long as Jitter Eater is either off or stays below 70. 80 = -107.1db-0.15db. Meaning, when moving the SM fader it will only reach from -107.1db to -0.15

That would imply that you need to use a higher value for fader_minimum_midi. With those settings, apparently the lowest value sent out by your StudioMix faders is not low enough to reach the low end of the defined ('calibrated') range, which is the point which matches minus infinity on REAPER's end after conversion.

Your earlier log data seemed to show that your faders aren't able to get down to 0, either.

Then, try switching fader_minimum_osc back to 0.002514. You were compensating for using a too low value at the other end. REAPER doesn't go any lower than 0.002514 there, so sending lower values is useless.

Originally Posted by N2NPro

Dead Zone; tested between 0-8000. No noticeable difference at any setting.

The Jitter Eater range seems to be happy about 30-70 before losing range.

With the 'dead zone' at 8000 (which is obviously way too high), I'd expect not to see any effect of the 'jitter eater' anymore (as it would only be active in the middle 383 out of 16383 values). And with a value greater than jitterDelta, I'd expect no loss of range.

Originally Posted by N2NPro

It does eat some jitter but does not cure it.
How to test Jitter:
Insert 32 tracks = no jitter

Is this also true when the 'jitter eater' is switched off?

Originally Posted by N2NPro

Aux Knobs no longer function... I will take a look at it.

Those need a similar cleanup as the pan controls, it seems to be the same type of problem (namely: the 'special variables' can all too easily get mixed up; so I try to avoid performing calculations with them directly, which also may make things slightly more human-readable).

Originally Posted by N2NPro

The Pan goes hard right when feedback is happening and you try and turn a pan knob. When feedback is not happening, pan works great all tracks.

I probably can't reproduce the same feedback you get... but will take another good look.

Originally Posted by N2NPro

I tried your Solo/Mute code and 6,7,14 don't work for me. The only way I have found is by using custom actions to give a new Cmd ID. The new Cmd ID works...

That's weird...

[N2NPro]

Banned,

Good god man, I think you are on to something!!
The timer mechanism seems to calm my faders considerably. Even with Jitter Eater Off.
I will continue testing but this has nearly stopped all jitter/creep when scrolling either by mouse or SM.
Wonderful!!

I'll post back shortly with more test results.

N2N

[Banned]

LOL, so I *am* a noob at this stuff.

Turns out, there only is one array in JS/EEL2/OSCII-bot. I wrongly assumed I was working with several independent arrays... so that explains quite a lot of the issues we've seen. Volume fader values ending up as pan knob values, and so on.

Hopefully fixed now, so check out v0.81.

[N2NPro]

Hi Banned,
Early test of v081, we lost channel 4 volume...
I re-tested v08 and it lost channel 6 volume...
Pan works great on all channels.
solo/mute selected and Master mute do not work without my fix.
I have the timer mechanism set to 1.5 secs and the Jitter Eater "off"

Will post more shortly.

N2N

[jico27]

@Banned

Testing version 081

What is ok :

Transport commands
the jogs (7000 & 7001)
undo & redo
RW & FF
FWD BNK & PRV BNK
select buttons
the pans (perfect)
the nice debug mode
All the faders running smoothly now
less problems with several selected tracks (when faders act as a group)

What is not :
Many adjustments done before all the faders get steady, when several tracks selected.
Still too many messages sent to the StudioMix and changing one or several faders values when a button arm is pressed on any trk in reaper
Solo sel / Mute sel
Mute master
Hotkeys won't open plugins if 'select track' has been done on the studioMix


@N2N

Testing N2N version

I don't think i can help much on that one since i still don't understand clearly what jitter/eater is doing
On the whole, i can't tell many differences with v.081, except that volume 6 is lost, that pans don't work and that mute master is ok. For the rest it's quite the same.

Hope this helps

[jico27]

back to v.081

Just one question: i am experiencing no change at all, when
rotary_pan_step_size = 1/200;
is set to different values (from 1/128 to 1/1024)
to what value should i set it to reach the maximum (100% R) with just 1/2 turn clockwise
Currently i have to make at least 3 half turns to reach this value

after more search, i can see that pans 7, 8, 15, 21, 23, don't work right, too

[Banned]

Originally Posted by jico27

back to v.081

Just one question: i am experiencing no change at all, when
rotary_pan_step_size = 1/200;
is set to different values (from 1/128 to 1/1024)
to what value should i set it to reach the maximum (100% R) with just 1/2 turn clockwise
Currently i have to make at least 3 half turns to reach this value

That depends on (1) where the pan position was before turning clockwise, and (2) how many MIDI messages the knob sends per rotation. I have no idea about (2), you tell me...

Also, note that there is a trade-off between 'responsiveness' and resolution. For example: if you would set

rotary_pan_step_size = 1/2;

... it would take just one or two 'increment' messages - but you can only set pan to hard left, center, or hard right.
If you would set

rotary_pan_step_size = 1/20;

... it would take 20 'increment' messages to go from hard left to hard right - but you can only set pan in steps of 10%.

[Banned]

Originally Posted by jico27

What is not :
Many adjustments done before all the faders get steady, when several tracks selected.

I'm not sure what you mean exactly. Can you try to be be a bit more specific?

Originally Posted by jico27

Still too many messages sent to the StudioMix and changing one or several faders values when a button arm is pressed on any trk in reaper

Again, we would need to identify which prior steps (can) lead to this issue; I don't see messages *every* time a track is (un)armed for recording.

When I have seen messages coming out of REAPER in such circumstances, they did not *change* the volume or pan on any track, though - they simply sent out the *current* values. So this should not be "changing one or several faders values."

Originally Posted by jico27

Solo sel / Mute sel
Mute master

I guess you have the same problem as N2NPro noted: 'regular' actions do not seem to work. I don't know what causes this issue. But perhaps you can also try to use the workaround using custom actions N2NPro explained above, at least for the time being.

Originally Posted by jico27

Hotkeys won't open plugins if 'select track' has been done on the studioMix

You need to be more specific what exactly you are doing there, I have no idea which hotkey you're using and what it's supposed to do.

[Banned]

Originally Posted by N2NPro

Early test of v081, we lost channel 4 volume...
I re-tested v08 and it lost channel 6 volume...

Originally Posted by jico27

after more search, i can see that pans 7, 8, 15, 21, 23, don't work right, too

I'm not seeing the exact same thing here, but I did see some similar bugs... while I'm only beginning to wrap my head around memory management in EEL2, feel free to blame it on me being a noob using you guys for guinea pigs.

[N2NPro]

Hi Guys,

Originally Posted by Banned

I'm not seeing the exact same thing here, but I did see some similar bugs... while I'm only beginning to wrap my head around memory management in EEL2, feel free to blame it on me being a noob using you guys for guinea pigs.
Today 09:10 AM

First off, Oink..Oink!
Thanks very much for all your time, energy, knowledge and generosity!

Originally Posted by jico27

Hotkeys won't open plugins if 'select track' has been done on the studioMix

Meaning, SM track select does not work in combination with some keyboard functions, ie. "ctrl", "shift", and jico27's hot key to open FX windows, etc.

My settings atm:
Timer Mech= 1.5 sec (works pretty good at 1.0 but 2.0 is too much latency)
Fader Calib= ON, max=15871, min=0
Fader Re-Scale= ON, max=0.716, min=0.0 (0.002515 does not produce full inf range)
Jitter Eater= Off
Dead Zone= 0 (Off)
Rotory Assign= 1/128 (smoothest for most of my FX)
Rotory Pan= 1/99 (2% increments per click/turn of the knob. 1/100= uneven R/L balance)
All of my pan channels work v8.1

v8.1 Channel 4 error LOG:
Channel Fader 1 LOG-
[MIDI>OSC] Track 1 Volume = 0.000000 [FLOAT]; TIME: 2359.577 > 2357.390: PASS
FADER 1 VALUE: 15946 [14-bit] +> 0.716000 [FLOAT] +> SENDING VALUE to REAPER

Channel Fader 4 LOG-
[MIDI>OSC] Track 1 Volume = 0.000000 [FLOAT]; TIME: 2419.609 > 3503.000: BLOCK
[MIDI>OSC] Track 1 Volume = 0.000000 [FLOAT]; TIME: 2419.624 > 3503.000: BLOCK
[MIDI>OSC] Track 1 Volume = 0.000000 [FLOAT]; TIME: 2419.645 > 3503.000: BLOCK
[MIDI>OSC] Track 1 Volume = 0.000000 [FLOAT]; TIME: 2419.706 > 3503.000: BLOCK

*neither measurement is the full range, only an example.
Channel 4 works when moving mouse (SM fader mirrors). Moving SM fader 4 has no affect over Reaper track. So feedback works.

*EDIT*
Channel 4 mysteriously started working! I insert an effect on its mixer channel and the fader started working.
I closed/opened Reaper and OSCII-bot several times and it still works (without having to load n effect on the channel. Here is it's new LOG;

[MIDI>OSC] Track 1 Volume = 0.000000 [FLOAT]; TIME: 4380.888 > 3503.000: PASS
FADER 4 VALUE: 15963 [14-bit] +> 0.716000 [FLOAT] +> SENDING VALUE to REAPER
-------------------------------------------------------------------------------------

I don't know what to say... Suddenly started working.. Scratching my head...
Banned?? what do you make of it??

With these settings fader jitter/creep is very minimal. Moving banks either via mouse or SM doesn't as many fader creep errors. In fact almost none (the suspect track 6 is the issue I believe). I am testing with 48-60 track projects.

Regardless of the version SM still sputters and puts out messages (kind of Parkinson's disease,- please, no offense meant toward people with that terrible, disabling disease). The Time Mech really helps calm it down but still gets bust at very random times. This makes it difficult to report due its inconsistent behavior. I think it's just the nature of the beast as SM behaves similarly in it's native Sonar app. I have used it for years through many Cakewalk incarnations from v8-S5, all behaving the exact same way- a bit Parkinson'd.

I am still experimenting with some setting but we're on to functionality that perhaps surpasses it's original performance. Less the fader creep, a very viable piece of gear in my studio.

Thanks again!
Will report soon with results... Btw, I had a go at Channel 4 but alas my skills are to weak... I look forward to the next batch of goodies!!

N2N

[Banned]

Originally Posted by N2NPro

Meaning, SM track select does not work in combination with some keyboard functions, ie. "ctrl", "shift", and jico27's hot key to open FX windows, etc.

I'm not sure if that is actually supposed to work - but arguably, it should. It seems that we'd need to report it as a bug / feature request to Cockos.

Originally Posted by N2NPro

Fader Calib= ON, max=15871, min=0
Fader Re-Scale= ON, max=0.716, min=0.0 (0.002515 does not produce full inf range)

Read this post above again. You're simply not able to get to -inf dB because your minimum value for fader calibration is too low.

Originally Posted by N2NPro

Rotory Pan= 1/99 (2% increments per click/turn of the knob. 1/100= uneven R/L balance)

Again, the pan balance is not uneven. The GUI display of pan settings is simply misleading because its rounding off values. The values sent out via OSC are *much* more accurate than what REAPER is showing you on the screen.

For finding the most finding suitable values, I wouldn't pay too much attention to the numbers on the screen, but focus on what 'feels' good ergonomically, while avoiding sonic artefacts (such as the 'stepping' you get when using too large increments).

Originally Posted by N2NPro

Regardless of the version SM still sputters and puts out messages (kind of Parkinson's disease,- please, no offense meant toward people with that terrible, disabling disease). The Time Mech really helps calm it down but still gets bust at very random times. This makes it difficult to report due its inconsistent behavior. I think it's just the nature of the beast as SM behaves similarly in it's native Sonar app. I have used it for years through many Cakewalk incarnations from v8-S5, all behaving the exact same way- a bit Parkinson'd.

I am still experimenting with some setting but we're on to functionality that perhaps surpasses it's original performance. Less the fader creep, a very viable piece of gear in my studio.

Good to hear we're getting closer. And yeah, there may be a few more things we can try to improve the behavior, but at some point, we may run out of options and will have to "live with it".

Now that we almost have the basics working correctly, we can focus on using the logging to try and spot the problematic patterns in the data more specifically.

Originally Posted by N2NPro

[...] I don't know what to say... Suddenly started working.. Scratching my head...
Banned?? what do you make of it??

There still are some memory related errors in the last version you're using. I'm debugging that stuff for the next version, now that I better understand how to use the single array as if there were multiple arrays in EEL2.

[N2NPro]

Hi Banned,
Thanks for your patience. I thought I tried that combo and failed...

New Settings for v81:

Timer Mech= 1.5 sec (works pretty good at 1.0 but 2.0 is too much latency)
Fader Calib= ON, max=15871, min=514
Fader Re-Scale= ON, max=0.716, min=0.002515
Jitter Eater= ON, 70
Dead Zone= 500
Rotory Assign= 1/128 (smoothest for most of my FX)
Rotory Pan= 1/99 (2% increments per click/turn of the knob. 1/100= uneven R/L balance)
All of my pan channels work v8.1

*I am not sure of the Jitter Eater/DeadZone relationship. Do these two setting seem appropriate? They do improve performance greatly when used with the Time Mech.

Channel 4 fader mysteriously came back. All faders now work.
Jitter/Creep decreased significantly. Seems channel 4 and 5 still send a bit of info post movement or when banking either by mouse or SM.

Panning 1/99 balance meaning, the display is the same on each side of "center".
@1/100 L=even numbers and R=odd numbers
@1/99 both sides of "center" produce even numbers. Of course if you take the knob past 100% it may change to all odd numbers, but that's still ok. They move in 2% increments. This is note worthy not due to accuracy but clientele, they may want OH drums panned equally-- if they see 12%L and 11%/13%R they may not like it. I can of course fine tune with the mouse but it defeats the purpose.

Originally Posted by Banned

Now that we almost have the basics working correctly, we can focus on using the logging to try and spot the problematic patterns in the data more specifically.

Example of post fader movement (32 track selected and moved by fader) LOG:
================================================== ===================================
[MIDI>OSC] Track 1 Volume = 0.716000 [FLOAT]; TIME: 9163.040 > 9163.929: BLOCK
[MIDI>OSC] Track 1 Volume = 0.716000 [FLOAT]; TIME: 9163.040 > 9163.929: BLOCK
[MIDI>OSC] Track 1 Volume = 0.716000 [FLOAT]; TIME: 9163.051 > 9163.929: BLOCK
[MIDI>OSC] Track 1 Volume = 0.716000 [FLOAT]; TIME: 9163.066 > 3503.000: PASS
FADER 1 VALUE: 16054 [14-bit] Previous1: 931 (delta=15123); Prev.2: 656 (delta=15398)
FADER 1 VALUE: 16054 [14-bit] is inside 'dead zone'; sending value
FADER 1 VALUE: 16054 [14-bit] +> JITTER EATER: SENDING VALUE to REAPER
-------------------------------------------------------------------------------------
[MIDI>OSC] Track 1 Volume = 0.716000 [FLOAT]; TIME: 9163.066 > 1.000: PASS
FADER 1 VALUE: 15998 [14-bit] Previous1: 923 (delta=15075); Prev.2: 0 (delta=15998)
FADER 1 VALUE: 15998 [14-bit] is inside 'dead zone'; sending value
FADER 1 VALUE: 15998 [14-bit] +> JITTER EATER: SENDING VALUE to REAPER
-------------------------------------------------------------------------------------
[MIDI>OSC] Track 1 Volume = 0.716000 [FLOAT]; TIME: 9163.066 > 9163.929: BLOCK
[MIDI>OSC] Track 1 Volume = 0.716000 [FLOAT]; TIME: 9163.066 > 9163.929: BLOCK
[MIDI>OSC] Track 1 Volume = 0.716000 [FLOAT]; TIME: 9163.087 > 9163.929: BLOCK
[MIDI>OSC] Track 1 Volume = 0.716000 [FLOAT]; TIME: 9163.095 > 9163.929: BLOCK
[OSC>MIDI] Track 4 Volume = 0.716000 [FLOAT]; TIME: 9163.112 <= 9164.612
[OSC>MIDI] FADER 4 VALUE = 0.716000 [FLOAT] +> 1.000000 = 15871 [14 bit, CALIBRATED]
================================================== ===================================
[MIDI>OSC] Track 1 Volume = 0.716000 [FLOAT]; TIME: 9163.134 > 9163.929: BLOCK
[MIDI>OSC] Track 1 Volume = 0.716000 [FLOAT]; TIME: 9163.273 > 9163.929: BLOCK
[MIDI>OSC] Track 1 Volume = 0.716000 [FLOAT]; TIME: 9163.485 > 3503.000: PASS
FADER 1 VALUE: 15989 [14-bit] Previous1: 16054 (delta=65); Prev.2: 931 (delta=15058)
FADER 1 VALUE: 15989 [14-bit] is inside 'dead zone'; sending value
FADER 1 VALUE: 15989 [14-bit] +> JITTER EATER: SENDING VALUE to REAPER
-------------------------------------------------------------------------------------
[OSC>MIDI] Track 5 Volume = 0.716000 [FLOAT]; TIME: 9163.522 <= 9165.022
[OSC>MIDI] FADER 5 VALUE = 0.716000 [FLOAT] +> 1.000000 = 15871 [14 bit, CALIBRATED]
================================================== ===================================


Example of post fader movement (32 track selected banked/scrolled) LOG:
================================================== ===================================
[OSC output] TRACK 8 PAN: 0.800000
[MIDI>OSC] Track 1 Volume = 0.800000 [FLOAT]; TIME: 9774.316 > 9769.011: PASS
FADER 1 VALUE: 9880 [14-bit] Previous1: 9811 (delta=69); Prev.2: 0 (delta=9880)
FADER 1 VALUE: 9880 [14-bit] JITTER EATER: too close to previous value(1), EATING!
-------------------------------------------------------------------------------------
[MIDI>OSC] Track 1 Volume = 0.437658 [FLOAT]; TIME: 9774.523 > 9775.673: BLOCK
[MIDI>OSC] Track 1 Volume = 0.437658 [FLOAT]; TIME: 9774.532 > 3503.000: PASS
FADER 1 VALUE: 9978 [14-bit] Previous1: 0 (delta=9978); Prev.2: 0 (delta=9978)
FADER 1 VALUE: 9978 [14-bit] +> JITTER EATER: SENDING VALUE to REAPER
-------------------------------------------------------------------------------------
[MIDI>OSC] Track 1 Volume = 0.442211 [FLOAT]; TIME: 9774.550 > 1.000: PASS
FADER 1 VALUE: 9981 [14-bit] Previous1: 0 (delta=9981); Prev.2: 0 (delta=9981)
FADER 1 VALUE: 9981 [14-bit] +> JITTER EATER: SENDING VALUE to REAPER
-------------------------------------------------------------------------------------
[MIDI>OSC] Track 1 Volume = 0.442351 [FLOAT]; TIME: 9774.550 > 9775.673: BLOCK
[MIDI>OSC] Track 1 Volume = 0.442351 [FLOAT]; TIME: 9774.550 > 9775.673: BLOCK
[MIDI>OSC] Track 1 Volume = 0.442351 [FLOAT]; TIME: 9774.585 > 9775.673: BLOCK
[MIDI>OSC] Track 1 Volume = 0.442351 [FLOAT]; TIME: 9774.585 > 1.000: PASS
FADER 1 VALUE: 10055 [14-bit] Previous1: 9981 (delta=74); Prev.2: 0 (delta=10055)
FADER 1 VALUE: 10055 [14-bit] +> JITTER EATER: SENDING VALUE to REAPER
-------------------------------------------------------------------------------------
[MIDI>OSC] Track 1 Volume = 0.445789 [FLOAT]; TIME: 9774.610 > 9775.673: BLOCK
[MIDI>OSC] Track 1 Volume = 0.445789 [FLOAT]; TIME: 9774.610 > 9775.673: BLOCK
[MIDI>OSC] Track 1 Volume = 0.445789 [FLOAT]; TIME: 9774.610 > 9775.673: BLOCK
[MIDI>OSC] Track 1 Volume = 0.445789 [FLOAT]; TIME: 9774.632 > 1.000: PASS
FADER 1 VALUE: 10123 [14-bit] Previous1: 10055 (delta=68); Prev.2: 9981 (delta=142)
FADER 1 VALUE: 10123 [14-bit] JITTER EATER: too close to previous value(1), EATING!
-------------------------------------------------------------------------------------
[MIDI>OSC] Track 1 Volume = 0.448948 [FLOAT]; TIME: 9774.665 > 9775.673: BLOCK
[MIDI>OSC] Track 1 Volume = 0.448948 [FLOAT]; TIME: 9776.273 > 9775.673: PASS
FADER 1 VALUE: 12943 [14-bit] Previous1: 0 (delta=12943); Prev.2: 0 (delta=12943)
FADER 1 VALUE: 12943 [14-bit] +> JITTER EATER: SENDING VALUE to REAPER
-------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------

I hope this helps...

N2N

[Banned]

Originally Posted by N2NPro

I am not sure of the Jitter Eater/DeadZone relationship. Do these two setting seem appropriate? They do improve performance greatly when used with the Time Mech.

It may make sense to define the one using the other, so you'd only have to tweak the 'jitter delta' value. For example:

deadzone = 2*jitterDelta;

(The 'dead zone' value should be at least the size of jitterDelta, or you could get stuck at the extremes of the range. Twice its value should be plenty for that. Maybe a bit smaller would still work better, try something like 1.25 or so too.)

Originally Posted by N2NPro

Panning 1/99 balance meaning, the display is the same on each side of "center".
@1/100 L=even numbers and R=odd numbers
@1/99 both sides of "center" produce even numbers. Of course if you take the knob past 100% it may change to all odd numbers, but that's still ok. They move in 2% increments. This is note worthy not due to accuracy but clientele, they may want OH drums panned equally-- if they see 12%L and 11%/13%R they may not like it. I can of course fine tune with the mouse but it defeats the purpose.

Yeah, I see. As long as you do realize that you are fooling your clients into doing exactly what they say they don't want. You may see perfectly symmetric values on the GUI, while those OH drums are still *not* exactly panned symmetrically, or vice versa, they may be panned perfectly symmetrical, but show slightly different values to each side of the center. For both of these cases, the difference is probably much too small to hear for panning - *except* near hard left/right - you may hear bleeding on the other channel while the panning display reads 100%L/R.

Put up a FR for more precise pan values displayed on the GUI, and you have my vote.

Originally Posted by N2NPro

Example of post fader movement (32 track selected and moved by fader) LOG: [...]

Hmm, those values look weird - like 14-bit MIDI values got into the timer mechanism array.

I still don't completely understand how memory / the array in EEL2 actually work, but think I have found a way to work around what I don't understand. So the next version should be a bit more reliable.

[Banned]

Next revision up for testing, v0.82. This should hopefully fix some issues with controls working incorrectly (which were caused by my incorrect use of arrays / memory in EEL2), and provide more reliable data to the log.

Btw, I found logging in OSCII-bot to be quite heavy on the CPU. So I would definitely suggest *not* using the debug mode for daily use, once we get the remaining issues sorted out.

[N2NPro]

Banned,
My early test of v82 show absolute perfection (less my solo/mute selected, Master Mute fix).
There is ZERO jitter/creep using your stock settings:

Timer Mech= 1.5 sec (works pretty good at 1.0 but 2.0 is too much latency)
Fader Calib= ON, max=15871, min=51
Fader Re-Scale= ON, max=0.716, min=0.002515
Jitter Eater= ON, 30
Dead Zone= 2*jitterDelta
Rotory Assign= 1/256
Rotory Pan= 1/200
All faders, pans, aux's, buttons functional perfectly.

Tested using 32-68 track projects. Scrolling whether via mouse or SM are smooth with ZERO jitter/creep. All tracks stay as the were set regardless of bank/track shifting.
I bought adult diapers for this moment but I didn't put them on in time... I shit myself all over again!!!

Banned, it seems you have out matched the original performance of the SM in it's proprietary platform. Cakewalk wished the unit worked as well with their own software, but it doesn't. I do not have words to express how impressive that is to me.

Here is the updated version bundled with the StudioMix.ReaperOSC "Bare Bones" file for anyone who might be interested:
http://www.n2nproductions.com/studio...bot%20v082.zip

Anyone using this will have to make 3 custom actions and assign solo/mute selected and Master Mute. Use the new Cmd ID's generated by the custom actions in the StudioMix+REAPER v82.txt file. Previous post #112 shows the code that will need to be copied over the original. Remember to use your own custom action Cmd ID's numbers.

Banned, I guess the only thing I would like to have is the Shuttle wheel functioning without me having to "pump" it to advance or rewind. The Jog works as I like (would be amazing to be able to have a step setting ie. 1/4 notes - Whole Bars). But other than that, it's absolutely fantastic!!!!

Thank you so much for your efforts!

I'll keep testing, let me know if you would like to have some LOG info.

You are the MAN!!

N2N

[jico27]

Thanks for your answers in #129, about the rotary_pan_step_size
I finally set it to 1/60, which works fine for me.
Handling the pan is now much easier.
And i also understood that it means that it takes 60 midi messages to go from hard L to hard R, i.e. 30 midi messages from center to either hard L or hard R.
Thanks for this too.

[jico27]

in #130

:
Originally Posted by jico27 View Post
Still too many messages sent to the StudioMix and changing one or several faders values when a button arm is pressed on any trk in reaper
Again, we would need to identify which prior steps (can) lead to this issue; I don't see messages *every* time a track is (un)armed for recording.

But this is what 'I' see. Those messages appear in oscii-bot 'every' time i press one of these rec arm buttons in reaper.
So ok... let's identify which prior steps can lead to this issue.
Can you please tell me how to proceed to do so?
(So far i've just followed your instructions from A to Z).

When I have seen messages coming out of REAPER in such circumstances, they did not *change* the volume or pan on any track, though - they simply sent out the *current* values. So this should not be "changing one or several faders values."

But again, the faders concerned move everytime this happens. So what's the cause of this? Could this be due to bad calibration or or unadapted values for re-scaling?
I'm just wondering.

[N2NPro]

Hi jico27,
Did you try the new v82 yet??
It has fixed all jitter/creep issues for me.

all hail Banned

[jico27]

:
Originally Posted by jico27 View Post
Solo sel / Mute sel
Mute master
I guess you have the same problem as N2NPro noted: 'regular' actions do not seem to work. I don't know what causes this issue. But perhaps you can also try to use the workaround using custom actions N2NPro explained above, at least for the time being.

ok. If i remember well, these actions worked in the earlier versions (not properly, but partially).
Is there a hope they could work ok in future versions?
I noticed that mute master is working in N2N version.
Is it possible to include his code in your script for a new version?

[jico27]

Originally Posted by N2NPro

Hi jico27,
Did you try the new v82 yet??
It has fixed all jitter/creep issues for me.

all hail Banned

ok i'll try this at once, instead of asking endless questions as i do! lol

sorry for this.

[Banned]

Originally Posted by N2NPro

My early test of v82 show absolute perfection (less my solo/mute selected, Master Mute fix).
There is ZERO jitter/creep using your stock settings:
[...]
Banned, it seems you have out matched the original performance of the SM in it's proprietary platform. Cakewalk wished the unit worked as well with their own software, but it doesn't. I do not have words to express how impressive that is to me.

That's great to hear.

Originally Posted by N2NPro

Remember to use your own custom action Cmd ID's numbers.

... and I would add: when things stop working after a REAPER update, check the Cmd IDs again. Read up on this here.

A more ugly, but also more stable (thus, better, imho) approach for using custom actions via OSC is to use the 'Custom ID' (which you can look up in the column next to Cmd ID in the action list, and) which is a long string that is guaranteed *not* to change between REAPER versions, like (for example):

_972d01de92474c04889cd9bbbdf8c8d5

Then you would use it doing something like this:

oscsend(destdevice, "s/action/str", "_972d01de92474c04889cd9bbbdf8c8d5");

I just tested that one, it seems to work fine here. So give it a try!

Originally Posted by N2NPro

9Banned, I guess the only thing I would like to have is the Shuttle wheel functioning without me having to "pump" it to advance or rewind. The Jog works as I like (would be amazing to be able to have a step setting ie. 1/4 notes - Whole Bars). But other than that, it's absolutely fantastic!!!!

Well, now we seem to have the jitter/creep issue out of the way, we can focus on fine-tuning things like that. What's there now is not much more than a naive first effort at getting things working. Can you try to explain as detailed as possible what you think should exactly happen? I'm afraid I don't have suitable gear to emulate how it works here. I'll try to add some more settings for tweaking the jog/shuttle behavior in any case.

[Banned]

Originally Posted by jico27

Is it possible to include his code in your script for a new version?

Yeah, sure - I can add them in the same script, so you would only have to comment/uncomment the appropriate lines using "//" characters.

The same goes for your MIDI/OSC I/O configs, btw, saving you the hassle of copying/pasting between versions.

[Banned]

Originally Posted by jico27

But this is what 'I' see. Those messages appear in oscii-bot 'every' time i press one of these rec arm buttons in reaper.

Gotcha.

Originally Posted by jico27

So ok... let's identify which prior steps can lead to this issue.
Can you please tell me how to proceed to do so?
(So far i've just followed your instructions from A to Z).
[...]
But again, the faders concerned move everytime this happens. So what's the cause of this? Could this be due to bad calibration or or unadapted values for re-scaling?
I'm just wondering.

It could be a number of things:
- REAPER may send redundant values (= little bug in REAPER);
- our script may contain errors (not unlikely at all... );
- and indeed, the problem may be exacerbated by poorly chosen calibration and/or re-scaling ranges, and the jitter/creep-feedback issue.

Now that I'm more confident that the data we're logging isn't bogus, we can think of how best to analyse this. Let me do some tests here, staring at the OSC output from REAPER.

[jico27]

Originally Posted by N2NPro

Hi jico27,
Did you try the new v82 yet??
It has fixed all jitter/creep issues for me.

all hail Banned

YES. Great job banned.

I want to join N2N to express my admiration for your talent.

Banned for the faders problems (and the rest), N2N for the tricky workarounds.
Success!

[N2NPro]

Hi Guys,

Well, I am happy to report v0.82 seems rock solid, 6 hours of usage last night in a paid, 16 track session. I was able to bring the Time Mech down to 1.0 sec for best response and no jitter/creep. I am so impressed, as I said SM functions better in Reaper via Banned's OSCII-bot code than it does in Cakewalk Sonar. I really take my hat off to Banned for this achievement!

Originally Posted by Banned

That's great to hear.
... and I would add: when things stop working after a REAPER update, check the Cmd IDs again. Read up on this here.

A more ugly, but also more stable (thus, better, imho) approach for using custom actions via OSC is to use the 'Custom ID' (which you can look up in the column next to Cmd ID in the action list, and) which is a long string that is guaranteed *not* to change between REAPER versions, like (for example):

_972d01de92474c04889cd9bbbdf8c8d5

Then you would use it doing something like this:

oscsend(destdevice, "s/action/str", "_972d01de92474c04889cd9bbbdf8c8d5");

I just tested that one, it seems to work fine here. So give it a try!

Yes, It works perfectly. Thanks for that tip. This will solve having to set it up again post future Reaper updates.

Originally Posted by Banned

Well, now we seem to have the jitter/creep issue out of the way, we can focus on fine-tuning things like that. What's there now is not much more than a naive first effort at getting things working. Can you try to explain as detailed as possible what you think should exactly happen? I'm afraid I don't have suitable gear to emulate how it works here. I'll try to add some more settings for tweaking the jog/shuttle behavior in any case.

The shuttle should respond by advancing/rewinding the play bar when the spring loaded knob is turned CW/CCW respectively. The knob has variable speeds/rates which should translate to the play bar accelerating when turned more and decelerating when turned less (makes it very easy to navigate to sections).

The Shuttle performance now is such that when the knob is turned 100% CW (4.4 time sig) it advances 7x 1/4 notes (1.1-2.4 measure/beats) and then stops. Upon releasing the knob, it advances again another 6x 1/4 notes (arriving to 4.2 measure/beats). If I need to go 30 measures into the piece, I have to "pump" the knob (turn CW and release over and over again until I reach the desired section. With one small turn and release it will travel 1x 1/4 note without advancing upon release of the knob. Difficult to navigate fluidly this way.

It would be nice to have the Jog snap to the grid settings while having the Shuttle flow with the speed generated by the amount of CW/CCW turn.

Another issue I'm seeing is; Clicking a track in the MCP or TCP does not cause the SM to go to that track. Mouse scrolling banks does make the SM follow the bank but not the specific track. It should function that when I select a track by mouse SM follows. I haven't found the right combo yet (Last_Touched doesn't seem to function). Please advise.

As you know, the ctrl, shift hot keys do not work in concert with SM. The Cmd ID's for Solo/Mute selected and Master Mute do not function as they should. You said these are bugs within OSC which should be reported. Are these unique bugs to SM or all users of OSC? Have other users with other controllers come forward with this?

OSC LAN Ethernet cable unplugging question:
I hate having my Studio PC connected to the internet, especially when working on intense audio projects. My PC has been optimized for audio and has no antivirus or firewall setup. I have tested OSC with my Ethernet cable unplugged and Reaper can't find the Host IP. However, if I start the PC with the Ethernet cable plugged and then unplug, Reaper finds the Host IP and functions normally. Is it possible to setup my LAN card in such a way where the Ethernet cable can remain unplugged and still have OSC function?

Again, I am forever grateful for you and your efforts!!

N2N

[Banned]

Originally Posted by N2NPro

Yes, It works perfectly. Thanks for that tip. This will solve having to set it up again post future Reaper updates.

Indeed. Custom actions are also very useful in combination with ReaScript, btw! Browse the forum for some good examples.

Originally Posted by N2NPro

The shuttle should respond by advancing/rewinding the play bar when the spring loaded knob is turned CW/CCW respectively. The knob has variable speeds/rates which should translate to the play bar accelerating when turned more and decelerating when turned less (makes it very easy to navigate to sections).

The Shuttle performance now is such that when the knob is turned 100% CW (4.4 time sig) it advances 7x 1/4 notes (1.1-2.4 measure/beats) and then stops. Upon releasing the knob, it advances again another 6x 1/4 notes (arriving to 4.2 measure/beats). If I need to go 30 measures into the piece, I have to "pump" the knob (turn CW and release over and over again until I reach the desired section. With one small turn and release it will travel 1x 1/4 note without advancing upon release of the knob. Difficult to navigate fluidly this way.

It would be nice to have the Jog snap to the grid settings while having the Shuttle flow with the speed generated by the amount of CW/CCW turn.

Ok, I think I get it. Now, let's see...

- Currently, the Shuttle (NRPN 7001) messages are translated to 'scrub' messages. So what happens in REAPER depends on these settings. For example, I tend to prefer small values (like 0.01) for 'Scrub-mode controller sensitivity'.

- The 'scrub' speed seems to relate to *absolute* time, not *musical* time. So, if you use a different BPM, the steps sizes will change. It would require a (feature request for a) change on REAPER's end to support musical timebase (as it arguably should, whenever a project is set to musical timebase).

- The 'scrub' feature does not seem to support 'relative' messages with acceleration. (Some other features, like scrolling, do.) Seems another good candidate for a FR.

- The 'scrub' mode only keeps moving the playhead as long as you keep sending it messages to move by another step.

These last two points imply that we need a relatively complex conversion scheme (including a timer mechanism) to generate a continuous stream of messages and send them out at the appropriate speed, depending on how far the wheel is off center. I'll have a go at it when I have some time.

But, re: "very easy to navigate to sections": you may want to experiment with markers/regions and

REWIND_FORWARD_BYMARKER t/bymarker
GOTO_MARKER i/marker t/marker/@
GOTO_REGION i/region t/region/@

... instead of all that tediously scrubbing.

Originally Posted by N2NPro

Another issue I'm seeing is; Clicking a track in the MCP or TCP does not cause the SM to go to that track. Mouse scrolling banks does make the SM follow the bank but not the specific track.

Well, if you are using the setting

DEVICE_TRACK_BANK_FOLLOWS MIXER

... then scrolling banks in REAPER makes the track *bank* follow REAPER's mixer perfectly: the leftmost track that is completely visible, is track 1 (i.e., the leftmost track in our layout) too. So that second part seems to be completely expected behavior?

Originally Posted by N2NPro

It should function that when I select a track by mouse SM follows. I haven't found the right combo yet (Last_Touched doesn't seem to function). Please advise.

The setting

DEVICE_TRACK_FOLLOWS LAST_TOUCHED

... is about the selected track, not the selected track *bank*.

And it seems to work as expected, too: for example, if you have 9 tracks, with the first 8 being part of the bank controlled by the device, and none are selected, then touching the fader on track 9 makes the 'regular' mute / solo commands target track 9.

What you want, seems to be a setting like

DEVICE_TRACK_BANK_FOLLOWS LAST_TOUCHED

... or

DEVICE_TRACK_BANK_FOLLOWS DEVICE_TRACK

... both of which do not exist yet. Yet another good FR.

But, in any case, I would think you can't have both: have the track bank follow *both* the mixer in REAPER *and* the last touched track. That would be inconsistent and confusing.

Originally Posted by N2NPro

As you know, the ctrl, shift hot keys do not work in concert with SM. The Cmd ID's for Solo/Mute selected and Master Mute do not function as they should. You said these are bugs within OSC which should be reported. Are these unique bugs to SM or all users of OSC? Have other users with other controllers come forward with this?

As far as I can remember, I haven't heard of other users noting it before. But it has nothing to do with the StudioMix device, and everything with how REAPER's OSC Control Surface feature happens to work at the moment.

It seems like you have quite a few good suggestions to make to Cockos already.

Originally Posted by N2NPro

OSC LAN Ethernet cable unplugging question:
I hate having my Studio PC connected to the internet, especially when working on intense audio projects. My PC has been optimized for audio and has no antivirus or firewall setup. I have tested OSC with my Ethernet cable unplugged and Reaper can't find the Host IP. However, if I start the PC with the Ethernet cable plugged and then unplug, Reaper finds the Host IP and functions normally. Is it possible to setup my LAN card in such a way where the Ethernet cable can remain unplugged and still have OSC function?

No idea. Fwiw, I can use local IP networking on my Mac just fine without wi-fi switched on or an Ethernet cable plugged in. But I don't know how your OS and networking hardware/software do things...

[Banned]

Originally Posted by jico27

YES. Great job banned.

I want to join N2N to express my admiration for your talent.

Banned for the faders problems (and the rest), N2N for the tricky workarounds.
Success!

Thanks, good to hear.

Do you still see issues with record (un)arming tracks, though?

[jico27]

Originally Posted by Banned

Thanks, good to hear.

Do you still see issues with record (un)arming tracks, though?

Hmm... actually they are almost totally absent now.
Some faders may move very slightly, even the master and I can hear it, because when a fader is moving, it is totally audible. I can also see it.
But these little moves don't affect the faders values sent back reaper. (I checked them before and after pressing arm/unarm several times. They are exactly the same).
The noises and moves produced by the motorized faders can be just the result of the actualization of the data received from reaper each time arm/unarm is pressed.

In case we'd need it again, is the debug mode a switchable feature, tweaking a line of code in the script?

[Banned]

Originally Posted by jico27

In case we'd need it again, is the debug mode a switchable feature, tweaking a line of code in the script?

Yes:

debug_mode = 1; // (0 = OFF; 1 = ON)

[jico27]

Originally Posted by Banned

Yes:

debug_mode = 1; // (0 = OFF; 1 = ON)

Thank you very much for this.
Here is what i notice when i press "arm":

================================================== ===================================
[OSC>MIDI] Track 1 Volume = 0.470000 [FLOAT]; TIME: 4685.922 <= 4687.422
[OSC>MIDI] FADER 1 VALUE = 0.470000 [FLOAT] +> 0.655214 = 10575 [14 bit, CALIBRATED]
================================================== ===================================
[OSC>MIDI] Track 2 Volume = 0.600000 [FLOAT]; TIME: 4685.922 <= 4687.422
[OSC>MIDI] FADER 2 VALUE = 0.600000 [FLOAT] +> 0.837418 = 13374 [14 bit, CALIBRATED]
================================================== ===================================
[OSC>MIDI] Track 3 Volume = 0.482000 [FLOAT]; TIME: 4685.922 <= 4687.422
[OSC>MIDI] FADER 3 VALUE = 0.482000 [FLOAT] +> 0.672033 = 10834 [14 bit, CALIBRATED]

And so on...

I'm just wondering if the calibration orders sent by reaper to the StudioMix each time a simple order like "arm" or "unarm" is used, are really necessary.
These orders have nothing to do with arm or unarm.
They don't bring anything indispensable to the studiomix in this context. They just make the motorized faders work for nothing.
Can't we stop them at the output of reaper in this case?

[Banned]

Originally Posted by jico27

Can't we stop them at the output of reaper in this case?

No, I'm afraid not. As you can see, these are simply volume messages. We have no idea of knowing whether they are related to track (un)arming. It's REAPER's job to minimize the amount of redundant messages (and as such, you may consider creating a bug report for this), but in doing so, it should of course err on the side of sending too much (i.e. redundant) messages rather than sending too few (in which case, the remote device would be out of sync because it did not receive the most recent value for all parameters).

[N2NPro]

Hi Guys,
I posted a bug report in OSC bugs/FR's. Please have a look. Let me know which one's I missed and I'll be happy to edit.
Btw, Ebay sold its recent StudioMixs after posting the OSCII-bot v82. We all owe you big time Mr. Banned. I acquired one from Craig's List, from the original owner (Lil' Ol' Lady from Pasadena)
Long live StudioMix!

N2N

[jico27]

Originally Posted by N2NPro

Hi Guys,
I posted a bug report in OSC bugs/FR's. Please have a look. Let me know which one's I missed and I'll be happy to edit.
N2N

I'm afraid i could find the link. Could you leave it for us here?
I'm looking forward to see them.
TIA

[N2NPro]

http://forum.cockos.com/showthread.php?t=96958&page=64
The bug list can be found here.

[jico27]

Originally Posted by Banned

Yeah, sure - I can add them in the same script, so you would only have to comment/uncomment the appropriate lines using "//" characters.

ok, so if you included his code in your last version, could you tell me which line it is at, approximately, so that i can uncomment it if necessary (especially for the 'mute master' function that used to work ok) because none of the mute sel/ solo sel/ mute master functions work at all with v.0.82.

TIA

Are you currently working on a new version?

[jico27]

Originally Posted by N2NPro

http://forum.cockos.com/showthread.php?t=96958&page=64
The bug list can be found here.

Ah! Thank you. Great.
Another FR that would be nice too is concerning the jog shuttle 7001.
Banned suggested that acceleration could benefit by relative messages
(in #148)

- The 'scrub' feature does not seem to support 'relative' messages with acceleration. (Some other features, like scrolling, do.) Seems another good candidate for a FR.

I think i do agree with this!

[jico27]

Originally Posted by jico27

ok, so if you included his code in your last version, could you tell me which line it is at, approximately, so that i can uncomment it if necessary (especially for the 'mute master' function that used to work ok) because none of the mute sel/ solo sel/ mute master functions work at all with v.0.82.

TIA

No, that won't be necessary. Sorry.
I finally made these three actions work with the custom actions i created in reaper and their CMD ID strings:

Mute master
→ oscsend(destdevice, "s/action/str", "_68745982aef83841943f98f7e247df22”.

Mute selected tracks
→ oscsend(destdevice, "s/action/str", "_903262c1881d6948958a6da2a91674bc");

Solo sel
→ oscsend(destdevice, "s/action/str", "_6dbed5cce5e35249b91ebb90d77f5bb9”;

Everything now works fine for me too.
Many thanks to you N2N!

I wish the FR you made will get some success with the reaper team!

[Banned]

Originally Posted by N2NPro

Hi Guys,
I posted a bug report in OSC bugs/FR's. Please have a look. Let me know which one's I missed and I'll be happy to edit.

Yeah, I'll have a look...

Originally Posted by N2NPro

Btw, Ebay sold its recent StudioMixs after posting the OSCII-bot v82. We all owe you big time Mr. Banned. I acquired one from Craig's List, from the original owner (Lil' Ol' Lady from Pasadena)
Long live StudioMix!

Haha, L'O'L'...

So, the next step would be modifying the script to support TWO StudioMix devices (e.g. for master + 17 tracks?)