Playfair Audio Dynamic Grading - new compressor

[muki]

for those who speak german:
here's the dev at musotalk

[jens]

Highly annoying as every Musotalk-episode... I envy those a little who don't understand any German...
(Yeah yeah, I know - nobody is forcing me to watch it... )

[Funky40]

whats the reported latency of this one ?

[hugoderwolf]

Thanks for sharing muki!

For English speakers, there's also a new video out where I talk about the mixing approach that becomes possible with this approach to dynamic processing:


I really need to make more of those videos...

There's also now a downloadable multitrack demo project that is mixed using this approach, so users can explore and play around with a practical example:
https://playfair-audio.com/dynamic-grading-demo-session

whats the reported latency of this one ?

It's variable and depends on the response time and latency setting.
Zero Latency: 0ms, obviously
Full Latency: 200ms constant
Smart Latency: one of 10ms, 20ms, 50ms, 100ms, 200ms, whichever is the next larger value to the response time

[DJErmac]

Wow, discount on this one !!
I’ve been waiting for a loooooooooong time !!
Purchased !

[Funky40]

This software should have a second mode.
At least do i suspect that my feature request would require to add it as a second mode.
This:
i´d like to see all 8 nodes completly independently CC mappable.
This would allow to create awesome one or two knob morph controls.

Such, would allow to use this plugin in way more advanced ways within "realtime-play" patches than right now.
It would further allow to create realtime-play mastering or remixing patches in way better ways than anyone would ever dream of right now.
Not complaining, just wishing

The zero latency mode is good enough for me.
While the "APU" comp, a quite similar tool, reports a latency of 10mSec.

Demoing it right now

[hugoderwolf]

Thanks a lot for your comments! CC mapping for this kind of design is extremely difficult and full of pitfalls. I've thought about that a lot and haven't found a really satisfying solution yet.

If you just map CCs to the node positions, what's supposed to happen if the topmost one is set lower than the next one? Should it stop there (as it does when editing with the mouse) or should you be able to turn it upside down? The internal parameters (that you can also map to CCs) are designed such that they can't collide that way, as is the way the graphical handles behave.

I might try to add some additional exposed "macro" parameters to resemble some of the things you'll typically do with the mouse. However, hosts can behave very weirdly and differently when you have parameters changing other parameters, let alone multiple at once.

That said, note that we are talking about a product that is specifically and intentionally designed to step away from knobs as much as possible. As a consequence, other features will likely have more priority in future development. Also, if knob-tweakability is your primary concern, we have to face the possibility that this product simply isn't suitable for your usecase, and what you might really want is simply a different product rather than a feature added to an existing one.

[Funky40]

Thanks a lot for your comments! CC mapping for this kind of design is extremely difficult and full of pitfalls.

i just sent you a PM.
but i was not aware of this aspect.

If you just map CCs to the node positions, what's supposed to happen if the topmost one is set lower than the next one? Should it stop there (as it does when editing with the mouse) or should you be able to turn it upside down?

i understand now why you´ve chosen the given solution

That said, note that we are talking about a product that is specifically and intentionally designed to step away from knobs as much as possible.

this has two sides to it.
I would guess, that with "stepping away from knobs as much as possible" you mean:
" stepping away from fiddling with virtual knobs with the mouse", no ?

Also, if knob-tweakability is your primary concern, we have to face the possibility that this product simply isn't suitable for your usecase, and what you might really want is simply a different product rather than a feature added to an existing one.

in general: not asking for an answer. I see your point !
just giving feedback:

No ! here you get the things wrong vs. me:
APU has 10mS latency ! that putts yours allready above the APU.
Not tested the ADPT tool so far.

I´d like to add this:
My wish vs. having 8 independently accesible nodes was totally in regards to "realtime-jam" uses. True !...thats a very specific task, true.

But overall, for any usecase, ...for any sort of production work, is some quick CC mapping, and working from dealing with real HW controls often the way better and way quicker deal "to learn to know a new tool", and "to find the desired settings with a new tool". Especially with tools, which are "complex in use vs. the musical context".
This one sums up to:
"knob tweaking" vs. "adjustment works".
In both cases *is* CC mapping a useful thing. Please don´t underestimate that one.

i often do CC mappings with the sole purpose to find way better and way more intuitiv my desired settings. Its not just about to jam around.

Lets leave my specific 8 nodes CC mappability off the table:
The CC mapping as is, needs some overhaul ! its imho a given.
But i understand now why you´ve chosen to do it the way you did !

personally, i will use your Tool from now on !
it allready adds ALOTS to the table to my uses => as is !
no latency ! Plus, to me, a very acceptable CPU load ! (Mac M2pro)

So no, its not "Not" for me. It IS for me.
But i have wishes open......... (not only vs. morph setups, but CC mapping in general ( also within your given thinking sheme)

I hope you can find a way to circumwent the aformentioned problem, that moving "one node alone" , could lead to the fact that it "collides" with the setting of another node.
I understand that. I see your point.
The nodes don´t need necessarily a own CC each.
But the ranges CC should look different........i hope you will put some effort into this one, to find a solution to overcome "the problme" from a programmers standpoint.
It would be MUCH appreciated.

this type of Tool brings a *immense" usefulness to the table !
for many different tasks. Also realtime play uses.
I´m in fact very ethusiastic about it

[hugoderwolf]

I would guess, that with "stepping away from knobs as much as possible" you mean:
" stepping away from fiddling with virtual knobs with the mouse", no ?

More like stepping away from the concept of a knob at all, as a one-dimensional way of manipulating a single parameter, which is borne out of the traditions of electronic hardware. I'm not sure if we'd have the concept of a knob or slider in an alternate universe where we never had electronic hardware with mechanical potentiometers, but rather just invented graphical user interfaces first.

The vision and intention behind Dynamic Grading is providing a kind of "object representation" of audio dynamics that can be directly manipulated. Like bending a metal sheet, or shaping a piece of clay. It's still channeled through a mouse and not as haptic as a knob, but the control and display of information are combined into one thing, which is something that physical knobs can't provide. It's too detached from the visual representation of what you or working with.

[camsr]

If rotary encoder controls are used instead of potentiometers, I think it may work by software definition of limits so one node does not cross another. It could also relay the control into the neighboring node if desired. I am unaware if there is any way a MIDI controller can specify that it uses a continuous control versus a fixed range, but that would be useful also.