View Single Post
Old 8th December 2017
  #17
Lives for gear
Quote:
Originally Posted by kodebode View Post
Great Idea.

My thoughts, we are so spoiled in 2017, with the quality and number and thoughtfulness of plugins, and amazingly many of these are freely downloadable.

Sadly there are only 24 hours in a day, and many of these gems go unnoticed, and underutilised.

Thanks for this TBProAudio. I do hope it gets used, looks awesome, like hardware!
Initial Follow Up/Feedback, further to my initial use.

1. Display

Tried this out, looks great, if a bit large on my 1366 x 768 resolution 15 inch diagonal laptop display. Not unusual, noticed that more recent plugins also seem to take up far more screen estate, than older plugins, probably the effect of monitors/displays with so much more resolution as technology/cost has evolved.

I can imagine that on a larger display/higher resolution display, this would look just about right.

On the display I guess its always going to be a bit of a juggling act, between aiming to fit on a variety of screens, as probably the easiest way to encode the display widgets is to use a fixed size.

2. CPU

My dual core i5 laptop throttles down to 1.5 Ghz - so this may not be representative of the median processing power of many users, but using Reaper which is considered the most efficient DAW, which adds the least overhead. over and above the CPU demands of each plugin - at least this has been my experience.

CASE 1 - Monitoring a recording via the DAW

Not unusable, but when used during monitoring of a recording, monitoring via the DAW, (and in my case conservatively set the audio interface/DAW buffers to 1024 - to introduce the least load from CPU interrupts by the audio interface)

So @ 1024 samples buffer size and also @ 567 samples : ISOL8 uses between about 2.5% and 4.5% CPU consistently as reported by Reaper, depending on where my CPU speed is between its Turbo boost of 2.3Ghz and its throttled speed of 1.5Ghz , higher CPU speeds yield a lower CPU usage for the plugin.

CASE 2 - During Mixing - with monitoring/recording via the DAW off

Reaper reported about 0.1% less for the values above.

Using the 48dB per octave setting instead of the 24dB per octave filter setting, almost doubles the CPU usage in either of the cases reported above, to between 4.6% and about 8%, depending on the variable laptop CPU speed, and whatever else was running in the background (Windows 10 !! - there are so many processes and things running in the background - not the best recipe for real time audio - my opinion, compared to plain old windows XP or Windows 7) - Rant - who needs Cortana eating up CPU cycles - Microsoft forcing their will on all of us, and we pay for it!!! - monopolies!!?

Everything works as expected - also checked the results via Voxengo's also excellent frequency analyzer - also free - another great indispensable tool.

In conclusion, for those who have the horsepower(CPU), this is a tool you can place anywhere, ideally on your master bus - to really understand the contribution of various frequency bands to the final result. I consider it an excellent listening tool. Pretty much like having your own mastering grade monitor controller. In many respects these are the kinds of plugins that really beg for tactile use - via a touch screen

In a full blown setup with multiple screens, e.g. Display 1 - Track Display 2 -
layout/sequencing, Mixer, and at least a third ideally with a touch enabled device - dedicated to displaying and controlling all monitoring plugins - for frequency, stereo, levels, VU meters, etc, plus ISOL8 as my master controller - all on one screen - with touch that would be awesome.

On that note the demise of Cakewalk and Sonar which probably made the most effort to be compatible with Microsoft's touch API's is regrettable.

The evolution plugin technologies from VST's earliest days have been awesome, so much is now possible in spite of the inconsistencies between evolutions in the plugin standards, operating systems, and the plethora of host DAW's that plugin makers are required to support - not an easy job.

If I had the money, I would pioneer a coalition of all affected parties, to develop a unified standard for audio/MIDI plugins, with full involvement of all the DAW makers, which much like Apples apps would also address the distribution of these - with an offline option, so that installs or reinstalls are not tied to the availability of the software manufacturer or the distributor (in case any of these businesses go bust).

The current challenge with plugins is that it is a bit difficult to effectively use any more than just a few - learn them very well, and track all the revisions, which many atimes have to done manually, or with every major plugin maker having their own custom online installation management tool!

This way we could also push certain functions like bypassing the plugin or things like muting the audio chain at this specific plugin in the chain, outside of the plugin as functions that no longer need to be duplicated in every plugin, in a slightly different way - and becomes part of a default set of automatable features of all plugins - provided by the host.

In my mind's eye - I also see services such as monitoring and frequency display, and even things like console emulation as subscription services/or higher level plugins, which could provide such services to all other plugins, this way, we could have a default monitor plugin that displays audio and controls audio from the currently selected plugin. Therefore each plugin maker does not have to incorporate these features in their product, wasting CPU cycles, only the currently selected plugin will consume display resources and CPU cycles, via these helper plugins. We end up with specialisation, plugin makers focus on what they are good at - processing, displays, etc, rather than the current inefficiency where a plugin maker is expected to excel at everything - coding, look and feel, distribution, - a new hopefully also an open ecosystem for plugins, that's what we need. This way I could use a plugin like ISOL8 on every channel, or on the output (or input) to every plugin, without having to set this up myself, manually - and eating up extra CPU cycles, like a contextual tool, enabled and disabled transparently in the background when needed.

Kinda like a linux and github for plugins - you get the idea.

Like google, I do hope we can use ideas such as these to completely rip up the audio engineering paradigm, way beyond all the current mechanisms that are bound to familiarity of traditional mixing precedents. With digital audio, technically - anything can connect to any other thing, and it should become a lot easier to do, than the current restraints of the existing plugin model.

Well we can only dream.

Thanks again TbProAudio.