2.1 feature requests

[120mg]

Non-destructive reverse for audio samples.

[Hengy]

select/edit and mute notes by colour
better midi clip grid functions
improved groove - extract groove from midi clip and apply it as a template to the grid on other midi clips
and enable % quantize to that grid, (muzys had/has a really nice groove implementation)
allow different quantise to difference coloured notes

if these exist you can shout at me all you like,
if they don't , they are my personal wishes, take them or leave them

[cbit]

like i said, jules is aware of the issues people have with freeze. if he decides that render and add really is not simple enough to do everything people want, and that there is a reason to change the freeze (considering that he's read it a billion times already) then he's going to be working on it.

sorry to rake this up again, but this strikes me as an odd outlook.. why shouldnt new users voice their opinions about this? So what that it's been posted n*1000 times before (by other users).. posting offers a way for people to make their opinion about the product known.

I think its handy for mackie/jules to know what people think of their product, and bizarre that some people who're satisfied with a certain feature chastise those who offer sugestions about how it could work better for them.

'get on with it' 'stop whining' 'find another host' i don't think these comments have any place here.. (any more than the term 'fanboy' does, at the other end of the spectrum) nuns with rulers lol (excellent image).

[spacefox]

Render clips in place:

Select clip/s and render them, ignoring any filters that are on the track (but with any filters on the clips themselves).
This means destructive editing features and merging audio clips with no hassle.

If we could drop filters on MIDI clips, it will even be more useful.

[pdxindy]

yeah yeah, but then i come along and point out that my hd faces problems way earlier than my cpu maxing out, so i maintain that freeze should work as it does, using one file for all frozen tracks so that hd load isn't bumped up with each cpu saving. this argument goes round and round forever. jules has seen it all, he doesn't need to see any more. if he has plans to put in different types of freeze then he has plans and will do what he thinks is best. til then, we just use render and add to achieve what you want.

Freeze has big limitations the way it is. It is ridiculously inefficient. If I have a longer composition, and I need to freeze 7 or so tracks to save CPU, the first track to freeze may take 4-5 minutes. The next track to freeze then takes 8-9 minutes (slightly less than half). By the 5th or 6th track, the freeze time is around 18-28 minutes. Then if I want to unfreeze one of those tracks, it is a 20 minute wait while it re-renders the other tracks. At that point it takes almost an hour to make a small edit? No thanks!

And don't ever hit the freeze button by mistake at that point, cause if you hit cancel it unfreezes all the frozen tracks and you have to start again, or wait the 1 hour it takes to freeze that mistaken track, and then unfreeze it again.

The current freeze wastes enough of my time that it is effectively useless. Then add in the fact that you cannot mute/solo, adjust volume or pan and I would not care if freeze was just removed from the program. I will never use it.

So render it is. I would like a 3rd option for render where it works like freeze (but don't call it that so nobody is bothered) in that the housekeeping is behind the scenes and there is not an extra track for each rendered track.

That is my feature request.

[braj]

yeah yeah, but then i come along and point out that my hd faces problems way earlier than my cpu maxing out, so i maintain that freeze should work as it does, using one file for all frozen tracks so that hd load isn't bumped up with each cpu saving. this argument goes round and round forever. jules has seen it all, he doesn't need to see any more. if he has plans to put in different types of freeze then he has plans and will do what he thinks is best. til then, we just use render and add to achieve what you want.

Freeze has big limitations the way it is. It is ridiculously inefficient. If I have a longer composition, and I need to freeze 7 or so tracks to save CPU, the first track to freeze may take 4-5 minutes. The next track to freeze then takes 8-9 minutes (slightly less than half). By the 5th or 6th track, the freeze time is around 18-28 minutes. Then if I want to unfreeze one of those tracks, it is a 20 minute wait while it re-renders the other tracks. At that point it takes almost an hour to make a small edit? No thanks!

And don't ever hit the freeze button by mistake at that point, cause if you hit cancel it unfreezes all the frozen tracks and you have to start again, or wait the 1 hour it takes to freeze that mistaken track, and then unfreeze it again.

The current freeze wastes enough of my time that it is effectively useless. Then add in the fact that you cannot mute/solo, adjust volume or pan and I would not care if freeze was just removed from the program. I will never use it.

So render it is. I would like a 3rd option for render where it works like freeze (but don't call it that so nobody is bothered) in that the housekeeping is behind the scenes and there is not an extra track for each rendered track.

That is my feature request.

I don't think it takes that long but you've made your point.

[djsubject]

[erik257]

On top of my wish list at the moment is some local loop option. Something like in Sonar. When you zoom into a midi editor and you want to loop around few beats and rulers are out of the screen, you have to first move cursor then press I or O etc. or zoom out and drug the rulers. Quite cumbersome don't you think. In Sonar for those who are not familiar with it you can assign markers on upper side of a midi editor window and loop around them.
At least option that you would be able to move rulers by keyboard keys instead of drugging them. For example ‘I’ plus arrow would move the left ruler ‘O’ plus arrow would move the right one.
And other thing probably easy to implement would be some mute tool for clips, like in cubase.

[valley]

erm, there are keyboard shortcuts pretty much like that.

'[', ']', and 'm'.

[erik257]

Really valley? I must have overlooked that. I will check it later. But in my opinion something should be done with looping anyway.

[pdxindy]

min/max options for midi controler mappings would be my favorite feature request

see Tassman synth for how they do it. Easy and fast. Set your slider or knob where you want it, define as min, set it where you want it for max, and define it as max. This makes it easy to invert a parameter.

no wait, make that my second favorite feature request. My number 1 feature request right now is the option to pay Mackie some money for T2 and unlock it!

[Mikael Adle]

A possibility to define from what key number the midi editor should display.
When either displaying two or four octaves, I would prefer to see C1 right away.

[Lunch Money]

I can definitely understand people's request for a different freeze option, even though I don't personally relate.

On the other hand-- an hour for a small edit? There's hyperbole for the sake of making a point, and then there's that.

[haydxn]

i'm not someone to say 'get a new host' at all. and i'm also not saying that the feature request is a pointless one. i AM however saying that everyone knows it's a feature request, and we're stupid to argue about it. there are 'for' points for all these freeze alternatives. you'll notice i pointed out my 'argument' about the current freeze because someone said 'freeze should only work like this (other method)'.

at the end of the day, yes all these points are valid. it's just they've been made a million times on this thread alone and yes we should just shut up about arguing either way, because the argument is out now and it's down to jules to decide what to do about it. you'll notice that i'm not actually backing either side.

[pdxindy]

I can definitely understand people's request for a different freeze option, even though I don't personally relate.

On the other hand-- an hour for a small edit? There's hyperbole for the sake of making a point, and then there's that.

You are correct. The figure I stated was inaccurate. It was 50 minutes, not an hour to unfreeze and refreeze one track, with 7 other frozen tracks. On an 867mhz G4...