v5 - a contrasting opinion, hope you don't mind

[ProfRhino]

Hi everybody,
first things first - big thanks and respect to everybody contributing to Reaper, full time programmers, semi-pro add-on makers down to folks sharing a handful of homemade buttons - great stuff, hard work, much appreciated and unique in the DAW world !
2nd things 2nd, Reaper is worth much more than the small fee asked for it, and the demo concept is the most user-friendly one imaginable, you can really get familiar with the program and make an informed purchase decision - I know I did, and I bought 4.x for what it was at the time, not for future improvement dreams.
Since this sub-forum is called Pre-Release Discussion however, please allow me to offer some related thoughts and opinions here, even if they might not follow the mainstream - no offense meant to anybody, just a single user's feedback.

- I'm not ashamed to admit I'm only a humble DAW user, no interest at all in programming or visual beauty (very keen on clear visibility though), my single priority is getting audio work (and a bit of Midi) done as efficient and intuitive as possible. I'd rather concentrate on the music and the other people in the room than ticking away a gazillion of checkboxes for every simple operation. Configurability and deep settings are a godsend to get seldom used options and details out of the way, but once set up for my personal needs I rarely want to touch them again.

--- So about the current v5 feature list, not many recording / mixing related improvements afaics, unfortunately.
Video - yeah, right. Don't need it personally.
New programming languages / options, whatever ? Great, how about using the existing ones for some useful real-world features first ?
Ex: OSC - nice, some folks even came up with a proof-of-concept for MIDI parameter feedback, how about an official, fully integrated version of this important feature ?
Combined with Reaper's flexible action system this would make HW controller mapping a best-of-class feature (S1 has the smoothest implementation but lacks options, C8 has a horrible implementation and no real focus mapping, but at least it has parameter feedback and a decent command set) - Reaper could have it all covered here, unfortunately in its current state working with controllers is a bit of a pain, kinda unfinished business, sorry.

--- on a very fundamental level, I feel Reaper's biggest flaw in general - gigantic options are no substitute for elegant, refined workflow for basic tasks, they are a very welcome bonus instead.
Ex: keyboard focus - am I alone wanting to use the keyboard to perform DAW tasks instead of typing stuff in plugins and child windows ?
In almost two decades I've never felt any need to do that, but how many billions of times have I done basic stuff like cycle, mute, solo, navigate, pan, wtf while having a few plugins open for reference ?
Please give us an option for no focus stealing by plugins and child windows, you can always activate a text field if needed, and assign a KC for specific functions ...
Mind you, not taking away the current system, but adding a more mainstream approach for those who want to assign plain keys to basic functions, like me.
Another example - Reaper could absolutely kill the competition with regards to multi-track audio handling - if it only had a few simple useability features added :
- a "folder edit" button ! With it enabled, all edits done to one track in a folder will be applied equally to all other tracks in that folder, simple and elegant as that. No grouping or other complicated tricks required. For individual edits just switch that button off. Combined with Reaper's stunning folders-as-groups feature, this would be the most elegant, mighty and intuitive multi-track edit workflow ever.
The building blocks are already there, it's a small subset of grouping, but it would be so much more than that ...
- same for comping, another bread-and-butter task. Would it be so hard to have take lanes behave similar to regular tracks like e.g. in Cubase, so you could cut up the takes in segments that can be freely edited, deleted, moved around, copied to and from other tracks / lanes ?
Obviously combineable with the abovementioned folder editing, that's where the advantages would really shine.
- without boring details, how about a context-sensitive info-line a la Cubase ? All the related information is already available somewhere in Reaper, why not present it in such a consolidated, space saving but highly visible way ? Everybody would love this little feature to death, I'm sure !
- last but not least, I've seen a request for consolidation of terminology (including SWS) - sounds totally boring, but the man absolutely has a point. Maybe unspectacular, but would really benefit every single user in the long run.

Sorry for the long post, I just wanted to put in a vote for useability- and workflow features (without taking away the more esoteric functionality of course) above anything else, put back the AW in DAW, please, that would be AWesome !

thanks for reading,
Rhino

... of course there are many other great, sensible requests, I could only list a few personal "favourites", but I hope you'll see the underlying paradigm - workflow, efficiency and ease of operation.

[whiteaxxxe]

Originally Posted by ProfRhino

... here comes the quote ...

+1 from me to ALL points mentioned. ALL.

[donchilcott]

+++++1

[maxdis]

Totally +1
Fix and finish the basics first, before adding more unfinished stuff on top.

[paulheu]

I agree with the idea that the Audio part of Reaper could use some work before moving into video. A simple function I really miss would be to have direct access to VST as we have in the mixer but available in TCP as well.

It's something I could really use and would greatly simplify my workflow. With projects growing larger and coming more frequent it will be something I expect to be using. And if Reaper can't deliver I guess other DAWs can (and do). Which will probably queue the 'feel free to start using that other DAW then' comments from some.. But it seems to me that is not the point.

[ivansc]

paulheu: Do you mean direct access as in like the shopping list-style slots in the mixer?

I am pretty happy to have the FX button and being able to see what is on a track in the TCP by hovering over it.

Perhaps I am missing the advantage you see here. Care to amplify a bit?

[semiquaver]

agree re: keyboard use and problems with focus -> very chaotic at the moment.

And yes the FRs seem worthy as well - I too am a (frequently frustrated) keyboard used and focus stealing is very annoying...

But the big changes in 50p1 are totally worthwhile imo - Making reaper scriptable and including useable languages, persistent scripts and an IDE will enable all kinds of great things to be generated. Reascript has been held back by being cumbersome and not portable - now with LUA and to a lesser extent EEL we will see a proliferation of interesting, distributable projects (think SWS and Playtime).

Likewise video support has been spotty - codecs and decoding have been fussy - the frame grid dodgy. The separation of video and audio editing progs is stupid: requiring round trips -> rendering stems or compressing video eating up tons of time. REAPER is on the frontier here and again I think we can't even see yet what a tool like this might be able to do. EEL video filters are impossibly cool...

Finally advancing video and scripting doesn't mean that nothing else is being worked on - propose your FRs and advocate for them and I'll line up to support them. In addition to these new very cool initiatives from the debs rather than instead of them

[ProfRhino]

semiquaver,
Fair enough about the video thing, all I said is I couldn't care less personally, different folks, different needs. I have a vintage copy of Vegas Studio 9, served me kinda allright for the one video job I did in 5 years.

Originally Posted by semiquaver

But the big changes in 50p1 are totally worthwhile imo - Making reaper scriptable and including useable languages, persistent scripts and an IDE will enable all kinds of great things to be generated. Reascript has been held back by being cumbersome and not portable - now with LUA and to a lesser extent EEL we will see a proliferation of interesting, distributable projects (think SWS and Playtime).

If that's the case, I'm all for it.
So far however (except for SWS which is excellent, ED's fine colour toolbar and a few useful eel scripts & actions), all I see is big ideas getting stuck in prototype stadium and people moving on to yet another interesting idea, similar to the theming scene. Looks more like a programmer's playground to me atm (nothing wrong with that, but not for me, I'm only interested in the AW part).
My guess - every finished, real world useable feature was about 10% creative inspiration and 90% boring routine work to iron out bugs, check compatibility and so on, can't reasonably expect that from people doing it for fun, not the slightest offense meant.
I'd rather see workflow-oriented, native low level features improved personally, the stuff you can't do with addons or bought plugins.
But I'll say it again, only some personal views, everybody's mileage will vary.
Rhino

[Tod]

Originally Posted by ProfRhino

If that's the case, I'm all for it.
So far however (except for SWS which is excellent, ED's fine colour toolbar and a few useful eel scripts & actions), all I see is big ideas getting stuck in prototype stadium and people moving on to yet another interesting idea, similar to the theming scene. Looks more like a programmer's playground to me atm (nothing wrong with that, but not for me, I'm only interested in the AW part).
My guess - every finished, real world useable feature was about 10% creative inspiration and 90% boring routine work to iron out bugs, check compatibility and so on, can't reasonably expect that from people doing it for fun, not the slightest offense meant.
I'd rather see workflow-oriented, native low level features improved personally, the stuff you can't do with addons or bought plugins.
But I'll say it again, only some personal views, everybody's mileage will vary.
Rhino

Hi Rhino, I have to ask, have you used any of these scripts some of these guys/gals are creating?

If you've got something special you want done, just ask for it. 9 times out of 10 they'll be able to do it, and 90% of the time it will do just what you need. It might not be fancy but who cares as long as it works.

That I think is the most redeeming quality of Reaper.

[plamuk]

regarding keyboard focus issues i agree. you can resolve this yourself by using / learning reaper commands to a dedicated midi controller. launchpads work great for this.

[paulheu]

Originally Posted by ivansc

paulheu: Do you mean direct access as in like the shopping list-style slots in the mixer?

I am pretty happy to have the FX button and being able to see what is on a track in the TCP by hovering over it.

Perhaps I am missing the advantage you see here. Care to amplify a bit?

One click access for one, drag 'n' move slots is another.. While at it having the option to add a VST to a specific slot and have it stay there would be good too (as in have a specific VST in the last slot always)

[ProfRhino]

Originally Posted by nym

regarding keyboard focus issues i agree. you can resolve this yourself by using / learning reaper commands to a dedicated midi controller. launchpads work great for this.

thanks, that's what I'm doing right now with 2 custom mapped BCRs, a Tranzport and a G700 keypad stuffed with "alt+", "ctrl+" etc commands .
It's a semi-decent workaround, but having the most intuitive controller right in front of me and not being able to use the plain keys reliably is such a waste ...
But credit where credit is due , Cubase 7 and later is even worse about focus, that's what made me look for alternatives after more than ten years of mostly great experience. 6.5 and earlier always had perfect focus behaviour and reliable workspaces when set up correctly.
Reaper could become the perfect alternative for Steinberg fugitives (and there is a lot of unrest, much more than their censored and hyped forums want to make you believe) - the potential is there no doubt, and catching up in the workflow department at least would make a switch easier.
I'm perfectly aware there are several areas where Reaper has definite advantages over Cubendo, but most of the disappointed users are from the recording / mixing crowd, requiring stuff like I mentioned in the op.
I'm still on the fence myself, using R4.7x and my grace period copy of C8 side by side, I'd love to be a single DAW person again, no matter which candidate ...
ymmv,
Rhino

[ProfRhino]

Originally Posted by Tod

Hi Rhino, I have to ask, have you used any of these scripts some of these guys/gals are creating?

If you've got something special you want done, just ask for it. 9 times out of 10 they'll be able to do it, and 90% of the time it will do just what you need. It might not be fancy but who cares as long as it works.

That I think is the most redeeming quality of Reaper.

thanks Tod,
I did, and people were very helpful, I'm very grateful for that and try to give back something myself in topics where I have a bit of experience.
I also learned a lot in the past 6 months, custom- / cycle actions, basic theme hacking for improved visibility, a multitude of Reaper-specific things and I am open for different workflow (actually learned to like Reaper's edit cursor concept a lot) - but it has to be roughly on par with what I'm used to, better would not hurt.
Please believe me, there is no disrespect meant in any way, this community is one of the friendliest and most helpful I've found yet, and I don't forget anybody who helped me out, no way.
My doubts were aimed at the general concept of adding more and more programming tools instead of concrete program improvements, not at the people using them and certainly not at those good folks generously helping others.
However, I don't see how scripts could help with stuff like I mentioned, this is what I meant with "native low level features", stuff that has to be implemented by the core team.
ymmv,
Rhino

[ELP]

+1 @Prof signed

First of all:
personally I, use often the scripting potenzial of Reaper and find also the upcomming Lua integration
very nice but....

Even 90 percent of the keyboard/synth virtuosos never create/screw own sounds. They often use only ready made.
Got what I mean?

(and now i mean not only Reaper Devs also many other Developer of music software)

So I think the adoption of Developers
that 95 percent -or so- of musicians from all music divisions are also scripting/programming professionals very strange.

What is Reaper?
A DAW for musicians with a great/outstanding
advantage for special functions over the scripting potential?

Or is Reaper a great/outstanding environment
for scripting virtuosos with the potential can be a DAW for musicians?

[j79]

I dont mind the scripting/programming stuff...personally i dont really use it, but to me its part of the reaper concept so to speak, and eventually someone will create something awesome that i will benefit from too. Even if they dont, someone else will benefit. i dont mind at all.

I am not so sure about video though...that seems a bit more "off" what Reaper has been in the past, more like branching out than further development of the core product. But again, i dont mind that much even if i wont use it.

I do agree however that there is some bugs/inconveniences in the already existsing core functionality that needs to be sorted. Time sigs, keyboard focus and other "oldies".

To me its not as much about what the devs choose to do as it is about what they choose not to do. And knowing how much stuff is usually worked on during a jump from one major version to the next, i am not worried at all. Not yet at least.

Since there is no set deadline, as least as far as i know, the "if they do x they cant do y"-thinkning is only partially valid if at all...

[ProfRhino]

agreed, no panic at all.
But in a pre-release discussion, it usually helps to present arguments early on, when the RC is out it'll not make much sense anymore.
Rhino

[ProfRhino]

@ELP,
no need to apologize for "unbeerable" language ...
you bring your point across clearly.
lol,
Rhino

[timothys_monster]

ProfRhino,

I totally agree. No need to throw in more FRs/improvements but I always had the feeling, that Cockos doesn't want to release "unfinished" work.

I know this "starting cool things but then - if it becomes difficult to implement - letting it fall" from other software companies (who also develop DAWs)... And I thought Cockos would be different. But this whole new focus on video scares me a bit.

I hope they don't get lost in it because, as written in other threads, the implementation of decent video editing can be very time consuming for developers.

I'd also like to see more A than V in my DAW of choice

[Lazarus]

I dunno, the Lua support smells pretty cool. The chances are every one of us has played a game or used something was written in Lua running on top of a super fast C engine (like Reaper's). We already know that at least one native Reaper feature is going to use Lua so all that's happened here is that the devs have allowed users to make use of what other companies can and do keep to themselves.

[cubic13]

I agree with Rhino general Statements/requests, especially the ones related to comping, keyboard focus and the lack of an interactive info line. And at this point, I would like to add mine, in a decreasing concern order :

1) I was expecting a 'Retrospective record' feature, at least for MIDI recording : just hope that we won't have to wait for Reaper 6 to see this one...

2) No changes concerning native NRPN inc/dec messages support for Reaper remote control : guess that I'll have to continue launching OSCII-bot processing a rather cryptic script, this with a virtual MIDI port before any efficient Reaper usage for a while...

3) The 'time' value of the project timebase is still not working : any change to the BPM value will shrink/expand any MIDI item, contrarily to what the 'project timebase help' states. See the following thread and report for more details :
- http://forum.cockos.com/showthread.php?t=143573
- http://forum.cockos.com/project.php?issueid=3412

4) Theming : the new tinttcp statement is welcomed (it works ; I just tested it), BUT :
- the tcp panel still doesn't move accordingly with the tcp_folderindent parameter, which means that we cannot define an area on the left of the panel which would mirror the track color choosed, if the involved track is in a folder.
- still no nested layouts.
- when the overall tracks width exceed the mixer window one, we sill have the horrible vertical gap between the master track and the other ones.
- Still no punch in/out or markers selection controls available in the transport panel.
- there are still no ability to create custom made buttons which could be add for actions (opening a VSTi window, quantizing, custom made ones...).
- I would also like a new theme file format which would include all the aspects of a theme, including toolbars, key map and menu sets.

5) The navigator is still as useless as it almost was (see here for more details : http://forum.cockos.com/showthread.php?t=147819).

6) I was also expecting a kind of track inspector which would have allow us to control everything track related : I'm thinking mainly of things like the track timebase or MIDI track controls/VSTi presets selection, among others.

Let's say that, for my own needs, there are sadly no true differences between the 4.75 version and the 5.0 pre x one : sure, the automation improvements are welcomed, but beside this...

[ELP]

looool @prof unBEERable
that´s the point^^

and +1 cubic13.

[nofish]

Originally Posted by cubic13

3) The 'time' value of the project timebase is still not working : any change to the BPM value will shrink/expand any MIDI item, contrarily to what the 'project timebase help' states. See the following thread and report for more details :
- http://forum.cockos.com/showthread.php?t=143573
- http://forum.cockos.com/project.php?issueid=3412

Longstanding issue for me also.
But actually, to be fair, it IS stated correctly in the timbase help imo.

Timebase time:
Project elements will keep their position and length constant as measured in seconds. Positions and media item length will change as measured in beats, if the tempo is changed. This was the default project timebase prior to REAPER version 4.25.

But who ever looks at this (especially as a new user) ?
Imo it would at least be better to call this timebase "Time (does not apply to MIDI items)" or something to avoid confusion until the behavior is changed.

[Triode]

Originally Posted by ProfRhino

- a "folder edit" button ! With it enabled, all edits done to one track in a folder will be applied equally to all other tracks in that folder, simple and elegant as that. No grouping or other complicated tricks required.

.

SPK wrote a script for this. I will post it here when I get back to laptop land.

[ProfRhino]

Originally Posted by nofish

Imo it would at least be better to call this timebase "Time (does not apply to MIDI items)" or something to avoid confusion until the behavior is changed.

Agreed about the issue, this type of "quirky behaviour" looks unwanted, at least for the majority of users.
Totally disagreed about your suggestion, though - reminds me of those helpful signs "road damaged" - well, better fix that thing instead of stating the obvious ...
@ cubic,
lots of good points, some even look like fixes for a .0x update.
My favourites out of your suggestions :
improved transport panel, navigator and theme file format.
I would like a dedicated preset format / option for all the user settings in the theme editor, I typically want to keep my event- and project page settings when changing themes, or transfer them between machines.
Having to manually hack those reapertheme files feels so '80s, and not in a good way.
cheers,
Rhino

[ProfRhino]

Originally Posted by Triode

SPK wrote a script for this. I will post it here when I get back to laptop land.

... say what ?!?
if that works, I'll dedicate my first beer every night to both of you for the next five years ...
no matter how this will turn out, huge thanks for the info !
I really searched high and low, we even had a long good discussion about the topic a while ago.
really looking forward to trying that script !
Rhino

[cubic13]

Originally Posted by nofish

Longstanding issue for me also.
But actually, to be fair, it IS stated correctly in the timbase help imo.

Precisely, it's not ! Let's look at this excerpt again :

Timebase time:
Project elements will keep their position and length constant as measured in seconds. Positions and media item length will change as measured in beats, if the tempo is changed. This was the default project timebase prior to REAPER version 4.25.


What's in bold is utterly wrong (believe me, I stumbled on it enough...). Let's say you recorded a 4 measures length MIDI item at 120 bpm. It has an 8 seconds length. Now :
1) Be sure that the project timebase is set to 'Time', and that the 'Set track timebase' option is set accordingly, either to 'Time' or to 'project timebase'.
2) set the project tempo to 150, with the dedicated transport control,
3) Result : the item has still 4 measures length, but has shrinked to 6.4 seconds. And listening to it leaves no doubt, sadly.

The only workaround to this, for each MIDI item already recorded, is to check the 'Ignore project tempo' option which is well hidden in the 'Source properties...' (ctrl+F2) dialog, this BEFORE applying any tempo change. Rather tedious when you are adjusting the project tempo to a new freely recorded piece.

Originally Posted by nofish

But who ever looks at this (especially as a new user) ? Imo it would at least be better to call this timebase "Time (does not apply to MIDI items)" or something to avoid confusion until the behavior is changed.

I agree, but the real problem is that it simply doesn't work as stated and moreover, we cannot easily change the project tempo according to a MIDI improvisation involving several items from, say, a multioutputs VSTi.

[nofish]

Originally Posted by cubic13

Precisely, it's not ! Let's look at this excerpt again :

Timebase time:
Project elements will keep their position and length constant as measured in seconds. Positions and media item length will change as measured in beats, if the tempo is changed. This was the default project timebase prior to REAPER version 4.25.


What's in bold is utterly wrong (believe me, I stumbled on it enough...). Let's say you recorded a 4 measures length MIDI item at 120 bpm. It has an 8 seconds length. Now :
1) Be sure that the project timebase is set to 'Time', and that the 'Set track timebase' option is set accordingly, either to 'Time' or to 'project timebase'.
2) set the project tempo to 150, with the dedicated transport control,
3) Result : the item has still 4 measures length, but has shrinked to 6.4 seconds. And listening to it leaves no doubt, sadly.

The only workaround to this, for each MIDI item already recorded, is to check the 'Ignore project tempo' option which is well hidden in the 'Source properties...' (ctrl+F2) dialog, this BEFORE applying any tempo change. Rather tedious when you are adjusting the project tempo to a new freely recorded piece.

I'm aware of all this and couldn't agree more that this behaviour should be changed, but still - (I admit it's getting into pedantic territory now ) I think it's described correctly in the timebase help. Because from what I know MIDI items are measured in beats and then the sentence I bolded in my quote applies (it 'overrides' the sentence you bolded' so to say, that's how I understand it at least).

[cubic13]

Originally Posted by nofish

I'm aware of all this and couldn't agree more that this behaviour should be changed, but still - (I admit it's getting into pedantic territory now ) I think it's described correctly in the timebase help. Because from what I know MIDI items are measured in beats and then the sentence I bolded in my quote applies (it 'overrides' the sentence you bolded' so to say, that's how I understand it at least).

No, it doesn't overrides it. Let's look again at my (tested) example. The results of the repro are :
- The length in seconds is shrinked (and the tempo of the playback is accelerated) / Excerpt : Project elements will keep their position and length constant as measured in seconds.
- The length in measures doesn't change / Excerpt : Positions and media item length will change as measured in beats, if the tempo is changed.

I emphasized previously what was concerning me the most ; the time shrink measured in seconds and the consequently altered playback. But actually, BOTH statements are wrong and Reaper behaves exactly at the opposite of what is described in this 'Project timebase help'. From which, the necessary and clumsy workaround described in my previous post to be able to adjust the project tempo without altering the content of any MIDI item. Just a reminder : strangely, this doesn't happen with audio ones.

But let's agree to disagree on this one...

[nofish]

Now I'm confused and not so sure anymore about what I wrote previously.
But anyways, yeah, let's leave it at that.

[semiquaver]

There is an sws action available to set the ignore project tempo attribute fwiw. The idea of time based midi items, sadly does not make much sense as they use beats and tempo internally. For example if a midi item was recorded across a tempo change marker the ignore project tempo setting will not yield the desired result.

A not officially supported solution is PiP.

[dea-man]

Can we make it so, whilst in a Reaper project, you can change time signatures and tempos at will, on the fly?

Is that to much to ask?

[Triode]

Hi Rhino

Here's a link to the script from spk77:

http://forum.cockos.com/showthread.p...88#post1450188

It works by selecting items in the folder rather than the folder itself. But the gist of what you're after is there I think.

For v5 new features I agree it would be great to be able to hide the tracks inside the folder and be able to comp and slice the folder itself.

Also I'd second your comments about keyboard focus. Especially for transport functions.

Happy new year

[ProfRhino]

Hi Triode & spk77,
this looks mighty interesting indeed.
Just checked it out, it really works !
And you can even follow it up with "select all items in track" for a nice custom action "select all items in folder", well, at least if you apply it where all tracks in the folder are populated.
Like you said, it's not exactly the same as a folder edit button, but it makes editing multiple tracks so much easier already ...
You guys are heroes !
This is exactly the type of workflow booster I'd like to see more of in the main program, a no-brainer to use, and yet so mighty !
Many many thanks, you made my day,
Rhino

I'll thank spk77 via PM asap.

[ProfRhino]

... oh, and of course a happy new year too !
Rhino

[ivansc]

Think I am going to stop reading the pre-release stuff.

I am starting to find the lack of focus on making Reaper WORK a little disheartening.

So many things that have been left on the shelf quite literally for years.
Maybe what it needs is for the devs to put us out of our misery and do a cull on the bug reports and FRs so at lest we KNOW if our pet peeve/want is still on the table or not.

Sorry - not wanting to be a downer but feeling a little frustrated and STILL missing a decent quality MIDI sequencer that works in a consistent, "expected" way within Reaper.Ditto the loopy Takes system.
If I had been forced to work that way with tape I would have slit my wrists (with a single sided razor blade) years ago. Is it really logical to do things the way they are currently done in Reaper????

[airon]

As painful as it may be, you gotta spill some more detail on those issue Ivan.

[cubic13]

Originally Posted by semiquaver

There is an sws action available to set the ignore project tempo attribute fwiw. The idea of time based midi items, sadly does not make much sense as they use beats and tempo internally. For example if a midi item was recorded across a tempo change marker the ignore project tempo setting will not yield the desired result.

A not officially supported solution is PiP.

I disagree, as Cubase handles this perfectly. As soon as you set the track timebase button to 'Linear', you can do whatever you want with the project tempo : a MIDI event recorded in the involved track won't be altered in any way and it's the same for an audio one. So, it shouldn't be rocket science...

And, as it is described in the 'Project timebase help', Reaper is expected to behave the same way. The fact that this bug is still there three years and a half after PooFox prefectly clear report (which, for a reason is still at an 'unconfirmed' status) is beyond me...

[Evan]

Originally Posted by ivansc

Think I am going to stop reading the pre-release stuff...

So many things that have been left on the shelf quite literally for years....

I somewhat agree with the sentiment. Not that I don't appreciate the new stuff in the early v5 pre-releases... I do.

It's just that for a brand new X.0 version, I was hoping for the following:

1) Take some bold desicions to fix/restructure/redesign existing stuff that has not been quite right... If there's any time to sacrifice some past version compatibility in order to set things straight, now is the time to do it.

2) Address some of the biggest and longest standing user annoyances or FRs.

I don't think either has happened enough in these first pre-releases. I recall v4 pre-releases being a little more succesful in these regards.

I just hope the v5 pre cycle lasts long enough to see more improvements before it hits final.

[j79]

I somewhat agree...but we are at pre2. I think its fine to bring it up, to keep poking, but its early days, so i am not worried yet.

But like i said, i do somewhat agree.

[dea-man]

Please fix adding tempo changes and time signatures on the fly!