Thread Rating:
  • 2 Vote(s) - 4 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Give us back "Bounce region with processing"
#11
(04-17-2017, 06:52 PM)madmaxmiller Wrote: ...
That screams for a script Smile
MMM

Haha, yes! I think everyone needs a Big button for this lol


-SD
Reply
#12
(04-14-2017, 09:34 AM)Ben@Harrison Wrote: If you are hitting the limits of your system, then it is possible to manually "bounce" the track (with all of the channelstrip instruments, fader, plugins, EQ & compressor settings) to a new track. Then disable the old track so it no longer uses cpu/disk resources.

And exactly this - if done by two buttons "freeze" and "unfreeze" - is called "freezing" to free up CPU-Power from VST-Instruments. It is done in most modern DAWs (Reaper, Cubase come to mind) since many years with a good reason: More and more people are working in the box from the beginning on with plugins.

I for example are using about 90% of the time VST Instruments, and only the rest is acoustical recordings. After 40 years of music production, i sold (almost) all of my hardware since many years, to streamline the production process as much as possible.

Once you have the opportunity to free up processor-resources in a uncomplicated, FAST way without thinking (easily reversable, also without thinking), you´re gonna use it in every single bigger project.

I´m afraid, you are orienting yourself too much on the traditional method of "a lot of tracks on harddisk" instead of "everything in the RAM", when determining the need for a decidedly "1-knob-solution" of freezing.

Honestly, i don´t understand, why you don´t simply build in such an comparably easy solution, that is simply workflow standard since years in most other big DAWs?

I do understand very well, that you don´t want to dilute your unique selling point "analog console", but should you therefore really renounce of implementing absolut usefull, contemporary features of a DAW?

The implementation of the workflow qualities of your mixing desks into software is great, but that alone is not sufficent for optimized work in a processor- and 2-D-screenbased workingenvironment of today, right?

Maybe you are making a mistake here?

Your argument, that due to increasing CPU-power the need for freezing wasn´t of that important anymore, from my experience is simply wrong. Every increase in processor-power is compensated after a while by increased demands of new software with new possibilities.

So, at least as long pcs are not a hundred or thousand times faster than today, there will be of course the need for a straight forward freeing additional processor power option - don´t you think? (Probably even then there probably will be 1024 bit-processing with samplerates in the GHz-range, which will eat up any gigantic cpu-power Wink....)

bye

Thomas
Reply
#13
(04-29-2017, 04:16 AM)niagara Wrote:
(04-14-2017, 09:34 AM)Ben@Harrison Wrote: If you are hitting the limits of your system, then it is possible to manually "bounce" the track (with all of the channelstrip instruments, fader, plugins, EQ & compressor settings) to a new track. Then disable the old track so it no longer uses cpu/disk resources.

And exactly this - if done by two buttons "freeze" and "unfreeze" - is called "freezing" to free up CPU-Power from VST-Instruments. It is done in most modern DAWs (Reaper, Cubase come to mind) since many years with a good reason: More and more people are working in the box from the beginning on with plugins.

...

I do understand very well, that you don´t want to dilute your unique selling point "analog console", but should you therefore really renounce of implementing absolut usefull, contemporary features of a DAW?

No, exporting to a new track is not exactly freezing. The "unique selling point analog console" is not only the surface but also the analog-like interaction between everything under the hood. If you "freeze" a track isolated from everything else you can miss things in the audio path. Developers can explain that (and have done that in the past) much better than I can.

What could be done easily is a Lua script which exactly does the described: Export a track with processing into a new one, rename the old one and deactivate it and put the pre-processed one in place. And vice versa. One knob without thinking.
However, I could imagine it's still not the same. When you work in other channels it could affect your "frozen" channel, too, but not in the way it would like with the "real" channel. Especially in 32C, which models real circuitry. Using "frozen" channels would be the equivalent of soldering another input to the master channel and adding a sound source which has nothing to do (processingwise) with the rest to the mix.

That's exactly what "other DAWs" are doing: Adding independant signal sources with no feedback. That's why they don't sound that good ootb.

I don't think, Ben makes a mistake here for the sake of an analogy to analogue processing.

So, my statement is, there can be a special export mode as described but it is not as easy as it looks like.

MMM
Reply
#14
(04-30-2017, 12:11 AM)madmaxmiller Wrote: No, exporting to a new track is not exactly freezing. The "unique selling point analog console" is not only the surface but also the analog-like interaction between everything under the hood. If you "freeze" a track isolated from everything else you can miss things in the audio path. Developers can explain that (and have done that in the past) much better than I can.

Sorry to disagree, but i think you´re wrong here.

I relate to exactly that, what Ben described - just not done manually with several actions/clicks after each other, but as a set of internal instructions, and triggered by a single "macro"-click.

That is no "export" to the outside world, its not breaking any dataroutine, that has to stay uninterrupted; its just an internal, nonrealtime runthrough of the actions, Ben described.

Nothing more. No interfering with the digital signal flow needed. You are at pause anyway, whether you do it manually or via a "macro"...

Look at it that way: What can be done as several steps "by hand" one after the other (what Ben described), can, in a shorter amount of time, as well be done as a summed routine after a single click. There´s absolut no difference structurwise regarding the handling of data between the two methods.

Quote: What could be done easily is a Lua script which exactly does the described: Export a track with processing into a new one, rename the old one and deactivate it and put the pre-processed one in place. And vice versa. One knob without thinking.

Well, so it ist obviuosly possible without interfering with the special inner structure of mixbus, right? Wink


Quote: However, I could imagine it's still not the same. When you work in other channels it could affect your "frozen" channel, too, but not in the way it would like with the "real" channel. Especially in 32C, which models real circuitry. Using "frozen" channels would be the equivalent of soldering another input to the master channel and adding a sound source which has nothing to do (processingwise) with the rest to the mix.

We shouldn´t make things too complicated here. A frozen track should behave like any other audio track - no interaction, no affecting each other etc.

Of course, you cannot expect to freeze a miditrack to an audiotrack and still expect it to somehow miraculously beeing able to interact, as if it still was a miditrack. Wink

Quote:So, my statement is, there can be a special export mode as described but it is not as easy as it looks like.

I think it is. You described it yourself with the simple lua idea, and Ben described it as simple actions done by hand.

We are talking OFF(!)line here, not realtime. As a result of this offline actions (whether done by hand or by a set of instructions), we simply have one more audio track, that can behave like any other recorded track, and be reconverted to mididata. Thats all.

bye
Thomas
Reply
#15
(04-30-2017, 06:50 AM)niagara Wrote: We are talking OFF(!)line here, not realtime.

Offline and realtime are apples and oranges.
Ben perfectly explained it already, who am I to try doing it again.

MMM
Reply
#16
(05-01-2017, 11:04 PM)madmaxmiller Wrote:
(04-30-2017, 06:50 AM)niagara Wrote: We are talking OFF(!)line here, not realtime.

Offline and realtime are apples and oranges.
Ben perfectly explained it already, who am I to try doing it again.

MMM


This might be a bit old but after reading most replies Ben still did nothing but give a work around to the request /question.what the person is asking for is the ability to quickly fix stuff like say tune a line in a vocal by simply inserting auto tune, eq, compress or add reverb to the line by offline bouncing it to the already recorded track in seconds.this has been possible since cub/nuen 3 and most daw years ago. The idea to add tracks and record is a slow process which kills ideas. There's also the not being able to pan in audio buss and I'm not talking about mixbus which is another topic. I think if these are done mixbuss will be hard to beat. Oh wait also I do see that theres some latency issues with mixbus and uad when plugins are inserted on audio busses and again I'm not speaking about the mixbusses.
Reply
#17
Adding to the original post, I have been doing this little "workaround" for years if a track has a lot or few but DSP hungry plugins:
- disable the master plugs
- either route and record the processed track into another track
- or export the processed track and import/drag into a new track (only take care of the same wave format)
- engage again the master plugs and the original processing is in the new track but DSP got decreased.
In the single core MB2 I did it a lot, and now in MB5 with plugs like Abbeyroad Plate eating up 15-18% DSP on stereo track it is still a way to stay under 90% not to get glitches.

What I really miss is an option in the track header menu to consolidate the track without selecting and rightclicking elsewhere...etc
And this really was there in MB2 and made it "Nice and Easy". Referring to Ben's priorities what we may do a lot times a day, it is also one of these tasks I think.
Win7/64, Mixbus32C, Mixbus2.5 the QueenSmile UR22, Dynaudio BM5A MKII, Pc all SSD,
Reply
#18
I too and, as it seems, a lot of others are yearning for this feature.
Seems to me the guys at Harrison are listening to the voices of their limitations rather than the voices of their customers.

It’s all good this analog emulation of a mixer. That’s why I bought it.
But that should not be a reason not to implement functionality that supersedes the times of the console itself.

In the very least, how hard could it be to create a lua script that exports selected track (midi or audio) offline, creates new audio track right next to the exported track, import exported file to new track, inactivates exported track and finally, selects newly created track. This should even be possible in the next update, considering your skills in lua.

Just for curiousa, Presonus Studio One has the ability to convert tracks from midi->Audio and vice versa, within the same track. With all the plugins and settings intact. In just a few seconds.

Technologies evolve, and so we must adapt.
If not, this DAW will become old and die in a hurry.

Peace.
Reply
#19
For sound design I like the ability to render plugins into regions and utilize freeze for processing heavy tracks. It’s a shame that Harrison is behind on these essential features. Emulating console workflow is the main appeal of mixbus but it is still a digital audio workstation.
Reply
#20
Thinking out loud here, haven't tried it, might be missing something, and late to the party...

Assuming all my processing is before any of the MB channel strip stuff, I could insert a send at the point in the chain I want to "freeze" - right before the MB channel strip.
Send that to another track, and record it there.
That recording would have all my processing on it, but not the MB channel strip.
Then, it could be used in a track (the same one it's on, or moved back to the original) and the MB channel strip processing could still be used with it to put it into the mix.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)