Stereo Tool

Have you tried (re)entering the license in the plugin from within VMIX? The standalone registration doesn't register the plugin version.

We typically test everythingin Reaper first. Do you have a retina (high resolution) screen? I got a similar report from someone else who thought that retina was causing it. Which is possible, the Macs in our office are rarely used so they are all hooked up to old lower resolution (1920x1080) monitors, so we could have missed that.


We're working on it, we have audio passing through it but the GUI doesn't show up. So we need to figure out what's wrong with that, then we can release it.


I think I made a booboo. I added that message a few weeks ago (the VST plugin requires *some* license to be present, and there was no message on screen that warned if you didn't have any but also weren't using features that are normally paid) but I heard from others (haven't had time to check yet due to IBC) that this message now pops up even if it's registered. If you see that things are registered on the registation page, you can *probably* ignore this message for now. (If there are no beeps or other messages after a few minutes, everything is ok).

Stereo Tool is a processor that makes developer level adjustments available in the user GUI. This distinguishes Stereo Tool from most processors, which offer only basic adjustments seen on audio processors for 40 years.

Audio processor adjustments are like notes in a sound palette. Imagine writing a song with four notes in a scale instead of twelve. Much more melodic flexibility with twelve notes in seven registers than four notes and nothing else.

Respectfully repeating my ongoing request that (1) all the adjustments in 9.92 remain available and (2) new versions have additional developer/designer level adjustments.

Please consider two GUI "skins" maybe green and blue that represent basic and full adjustment visibility.

I was motivated to post this again because someone suggested attack shape control was not needed. That bothered me because Stereo Tool controls recognize the time based nature of control action, such as slope and curve over time, and rate of change instead of a somewhat misleading simple term like "attack time".

Eventually Stereo Tool could have parameter visual display showing time on the X-axis and gain reduction on Y-axis, with a panel on the same screen with adjustments controlling action, and scalable gain reduction meter. It could be a full-screen window for each band's attack and release parameter. Or sizable as multiple windows for each band on a multi-band compressor. That is, a visual screen like the one for the programmable equalizer. User could "draw" a band control profile on the X-Y display, and clicking or hovering on a spot on curve could produce a pop-up with the numeric parameters of that spot. Example- -6 dB threshold, 5 ms time

Perhaps a visual display like this would enable a large amount of developer level adjustments to be understood by users.
Consider sound recording and reinforcement audio mixing consoles and control panels in aircraft. GUI design objective is providing as much control as humanly possible. For some time now the massive amount of adjustments in a mixing console have been made usable by humans by employing a layer approach. This is being done now in Stereo Tool, maybe expand this.

In essence, imagine Stereo Tool GUI as a cockpit in a commercial aircraft or a mixing console for a music concert. In both cases many interactive and complex adjustments must be made by humans, with consequences.

I note that I did a poor job of human engineering this lengthy post.

1) They are. They have clearer names and descriptions than before, but they're all there. Try CTRL SHIFT + to open all cells for more visibility.

2) No, the premise of this new GUI is to not have to maintain multiple operation modes. Your suggestion would defeat the purpose.

The rest of this post about graphing should probably be in the wishlist subforum since it's a major change.

I found something
AGC(current) bands: Sliders shows (for example 30Hz first band), but graph shows way to high slope point, that starts to "fall" at 200Hz. Is it right, or something is wrong? I thought, it`s suppose to be the "point of slope starting" - i.e. 30Hz.
Why is this "offset", if i can call it that way?

Another example is : (if 4 bands is selected), last band slider is at 24000 Hz, but high slope starts at around 11000 Hz.

MrKlorox- Thank you. You are correct. I think one operating mode would be excellent if it has a pathway to developer level adjustments. Like peeling off layers of an onion, or opening multiple doors to explore a house. User can stay in the living room or venture back to the lab.

I believe I posted suggestions on the wish list. But I am not wishing. For me this is not a game or a toy.

TNX

DJ-DOGGY- Based on my understanding of comment, here's my view- In a "conventional" multi-band processor a crossover point is the frequency where adjacent bands are at equal gain. If this is not the case then there would be unity gain (other set gain) between adjacent band crossover points. Then the process would be better described as dynamic equalization.

I can see situations where the lowest band and the highest band might have the option of setting two crossover frequencies, one on the upper and one on the lower side of the band. But this could be handled by adjustable band pass filter on the wide-band input of the multi-band control voltage side-chain. I mentioned this in the wish list. Band-pass or additional filtering/EQ of the side-chain can be distinguished from band-pass or additional filtering/EQ in the on-air audio path. Different effect and purpose.

It is well-known that you don't want to permit frequencies that will not be transmitted or heard to cause gain reduction on frequencies that will be transmitted or heard. Orban and other manufacturers have done this for a long time. Unless I have missed it, this capability is not present in Stereo Tool. I believe I suggested making a PEQ available for before the first gain reduction stage, after the de-clipper... Please prioritize improving underlying architecture and layout flexibility of Stereo Tool instead of making it work on every known device.

The recent (since the mid '90s) development is hard clipping on source material. This clipping becomes tilted by static and dynamic filtering/EQ in the audio processor, which in turn increases peak level of the clipped source material that is non-productive to the fundamental task and an annoyance.

Creators of source material generally assume their finished sound content is what will be heard. They process and mix like there won't be any more processing downstream. It's a bit arrogant. Orban, Telos, Wheatstone and Thimeo are seeking to make processors deal with source content that is already "done", yet can still go to work on content that is not "fully-cooked" Life goes on

But the truth is now many end users want to reprocess and "remix" another person's sound content, i.e. artistic creation or intellectual property.

Hello,

If I start the 10.10 shared library Stereo Tool with Liquidsoap, liquidsoap stops with the following error message:

At streamtranscoder.liq, line 12, char 2-68:
s=track.audio.stereotool(%argsof(track.audio.stereotool[!id]),audio)let replaces s=source(id=id,{audio=(s:pcm),metadata=metadata,track_marks=track_marks})s

Error 14: Uncaught runtime error:
type: invalid,
message: "Invalid stereotool library",
stack: at streamtranscoder.liq, line 12, char 2-68,
at streamtranscoder.liq, line 12, char 2-68,
at streamtranscoder.liq, line 35, char 2-202

There is no such problem with the previous version.
The old one has libStereoTool_64.so, the new one has libStereoTool_intel64.so. I renamed this accordingly.

Will it be possible to upload a shared library beta with the next beta version?

My view is processing cannot move forward if processing developers are focused on compatibility with low capacity hardware.
Software leads, hardware follows.

It is my understanding several well known hardware processors are consuming nearly all of their system resources. They can't add more artificial intelligence to the processing, the hardware is already pedal to the metal.

The physical hardware package accounts for much of the customer cost of big box processors. That money does not translate into profit for the processor manufacturer/developer as efficiently as software. In the end the customer spends about the same amount of money or time in either case.

Stereo Tool is reasonably priced, but I spend many weekends adjusting it, and that time is worth money. Same cost in the end.

I hope this explains my rants about efficient workflow, control descriptions, etc. I don't mean to be rude.