4.23pre7 - May 2 2012

[musicbynumbers]

4.23pre7 - May 2 2012
# JS: editor now top level window with icon
# JS: ctrl+up/down/left/right now do nice things in editor
# JS: left/right at start/end of lines now wrap to previous/next lines
+ JS: fixed bug where increasing track channels during playback with PDC-JS could cause dropouts
+ API: CreateNewMIDIItemInProject now takes a track parameter
+ Time signatures: added functions to rationalize time signatures
+ Time signatures: automatically rationalize time signatures when adding/removing time from project, or moving regions
+ Tempo markers: saner manual editing of tempo changes when "gradually transition tempo" is enabled
+ Crossfades: do not create auto-crossfade on one edge of an item when editing the other edge

[Kundalinguist]

Mommieeeeee!

[mabian]

Dadddieeee...

- Mario

[musicbynumbers]

Originally Posted by Kundalinguist

Mommieeeeee!

mommy? don't you mean "who's yer daddy punk?" lol, joking!

I got lucky this time, next time I'm sure will be yours again!

[miche]

Originally Posted by musicbynumbers

+ Time signatures: added functions to rationalize time signatures
+ Time signatures: automatically rationalize time signatures when adding/removing time from project, or moving regions
+ Tempo markers: saner manual editing of tempo changes when "gradually transition tempo" is enabled

Can we have more info on this? Does this fix the weird measure behavior when using time signatures different from 4/4?

[paterpeter]

Ach, wie nur kann ich bloß erziel'n,
dass ich mal wieder Freude hab,
wenn ich versuch was einzuspiel'n,
im MIDI-Modus "overdub"?

Denn wenn ich einmal Noten spiel,
bevor der Schleifenstart erreicht,
bekomm' ich derer viel zu viel,
ich denk' es ist ein Bug vielleicht.

Ist klar, dass ich das tracken ließ
als Bug (ID: vier-null-vier-sechs).
Und dann bei jedem Prerelase,
prüf ich die Changelogs im Reflex.

Doch jedes Mal bin ich enttäuscht,
es ist für mich nichts eingecheckt.
Zumindest nicht das, was ich bräucht':
ein Bugfix für den Code-Defekt.

Drum an den Cockos-Programmeur:
kannst du es arrangieren -
es ist auch sicher nicht zu schwer -
den Bug zu reparieren?

===

Please Cockos, look would you made me do! Have a heart, I beg you!

http://forum.cockos.com/project.php?issueid=4046

[Mercado_Negro]

+ Crossfades: do not create auto-crossfade on one edge of an item when editing the other edge

Thanks! That thing killed me for years

[EvilDragon]

Yes, more info about those timesig thingies is welcome...

[Marah Mag]

Originally Posted by musicbynumbers

+ Time signatures: added functions to rationalize time signatures
+ Time signatures: automatically rationalize time signatures when adding/removing time from project, or moving regions
+ Tempo markers: saner manual editing of tempo changes when "gradually transition tempo" is enabled

I haven't tested this yet... but even if this is premature... but thank you thank you thank you!

[IXix]

+ Time signatures: added functions to rationalize time signatures
+ Time signatures: automatically rationalize time signatures when adding/removing time from project, or moving regions
+ Tempo markers: saner manual editing of tempo changes when "gradually transition tempo" is enabled

Great to see this stuff getting some attention! The JS improvements are huge too but I already knew about those. 4.23 is shaping up to be a classic.

/me runs off to figure out what a rationalized time signature is.

[IXix]

Originally Posted by IXix

/me runs off to figure out what a rationalized time signature is.

It doesn't seem to fix my main problem with tempo and time signatures.

If I increase the tempo at a given point, all subsequent time/tempo markers should move to the left. If I decrease the tempo, all subsequent markers should move to the right. It fries my brain that they stay fixed where they are in time rather than moving with the tempo. Please, please, please fix it.

On a positive note though, WOOHOO GO DEVS! Don't want to sound too negative.

[mattfaulkner]

Originally Posted by IXix

If I increase the tempo at a given point, all subsequent time/tempo markers should move to the left. If I decrease the tempo, all subsequent markers should move to the right. It fries my brain that they stay fixed where they are in time rather than moving with the tempo. Please, please, please fix it.

I can think of a lot of situations where this would actually be preferred behaviour, so in my opinion this can't be something that should be 'fixed'. We need an option for both.

[schwa]

Originally Posted by IXix

If I increase the tempo at a given point, all subsequent time/tempo markers should move to the left. If I decrease the tempo, all subsequent markers should move to the right.

If you set the project timebase to beats, markers should stick to beats rather than time. (This has always been the case -- perhaps I am misunderstanding the report?)

[schwa]

Originally Posted by musicbynumbers

+ Time signatures: added functions to rationalize time signatures
+ Time signatures: automatically rationalize time signatures when adding/removing time from project, or moving regions

These actions are intended to fix the situation where time is added, removed, or moved within a project. Previously this could result in time signatures that don't make sense. For example, removing one beat from the project could previously could leave behind a measure of 4/4 that is only 3 beats long. Now it should create a new measure of 3/4.

[maxdembo]

Originally Posted by Mercado_Negro

Thanks! That thing killed me for years

Fantastic! Just today, this was annoying the bejesus out of me.

[XITE-1/4LIVE]

I don't apply this on audio, but can insert measures with blank space, only time signature and tempo change, and I didn;t have to rewrite the arrangement.
Also notice that the Time Sig/Tempo doesn't default back to the Project Tempo, but retains the bpm last used.

Nice touch and I hope this works as well for the audio guys that try it in their arrangements.
This also is great for Orchestral Scores where I always forget a measure with TimeSig/Tempo changes.
Never perform this stuff but enjoy a good challenge on my off days.

Thanks So Much....

[EvilDragon]

So, no changes related to other two problems laid out in THIS thread?

[ovnis]

Can we have more info on this? Does this fix the weird measure behavior when using time signatures different from 4/4?

It seems reapers 's dev never work in 3/4 or 5/4. So they dont care about our long time and seriously problem.

[mirceablue]

There is a way in Reaper to change tempo globally if you already have time signature/tempo markers, instead of changing tempo manually for each time signature/tempo marker ?

[moliere]

Originally Posted by mirceablue

There is a way in Reaper to change tempo globally if you already have time signature/tempo markers, instead of changing tempo manually for each time signature/tempo marker ?

Not nicely, but if you show the tempo map on the master track, then select all the points you can drag them up or down with the mouse together. Not ideal, but it's a lot faster than doing each one individually.

[mirceablue]

Originally Posted by moliere

Not nicely, but if you show the tempo map on the master track, then select all the points you can drag them up or down with the mouse together. Not ideal, but it's a lot faster than doing each one individually.

I figured out this one, but I wonder if there's a way to constrain the movement to exact tempos ex: 120..121...122, not 120.026 ..

[mirceablue]

Got it, there are action for this, i knew it . Yey

[EvilDragon]

Originally Posted by ovnis

It seems reapers 's dev never work in 3/4 or 5/4. So they dont care about our long time and seriously problem.

Yeah, it seems like that's the case


Let's not go into beautiful time signatures like 21/16...

[Banned]

Originally Posted by mirceablue

There is a way in Reaper to change tempo globally if you already have time signature/tempo markers, instead of changing tempo manually for each time signature/tempo marker ?

You can perhaps also use the play rate slider for that. But it won't be constrained to integer BPMs.

[IXix]

Originally Posted by schwa

If you set the project timebase to beats, markers should stick to beats rather than time. (This has always been the case -- perhaps I am misunderstanding the report?)

Ha, no you're not misunderstanding the report. I didn't realise the project timebase would apply to the tempo envelope points, that makes no sense to me. I wish I'd realised that a few months ago.

Anyway, trying it just now it does what I'd expect as long as there are no gradual tempo changes involved. If gradual changes are involved, time sig changes don't always stick to the correct measure, which I'd consider to be a bug. Tempo/time sig changes should stick to their measure/beat position like glue, no matter how crazy the preceding tempo variations may be.

It seems that you can't override the timebase for the master. It allows you to do so but it doesn't actually work. The envelope still follows the project timebase. If the master track timebase and the project timebase are actually supposed to be one and the same then changing one should change the other, which isn't what happens currently.

In any case, surely the master tempo envelope is a special case and should always have 'beats' behaviour, regardless of the project timebase. I can't think of a situation where it would make sense to say "at 1:20 change to 3/4 regardless of what measure or fraction of a beat you happen to be playing at that time".

[IXix]

While we're on the subject of timebase, would it be possible to implement more fine grained control over it? Setting the timebase for individual markers, regions and envelopes would definitely be handy. Maybe even overriding the behaviour of individual envelope points could be useful?

[EvilDragon]

Originally Posted by IXix

In any case, surely the master tempo envelope is a special case and should always have 'beats' behaviour, regardless of the project timebase. I can't think of a situation where it would make sense to say "at 1:20 change to 3/4 regardless of what measure or fraction of a beat you happen to be playing at that time".

CORRECT! Tempo envelope MUST be in beats timebase ALWAYS. This is a fundamental bug in Reaper.

[Banned]

Originally Posted by IXix

[...] Tempo/time sig changes should stick to their measure/beat position like glue, no matter how crazy the preceding tempo variations may be.[..]

When using a musical (beats/position/rate) timebase for the project, *everything* should stick to its measure/beat position (unless specifically set otherwise) on any tempo changes, whether pre-programmed or entered manually. Including the playback position, especially while playing (and preferably the zoom level of the arrangement window as well). At least there is no longer any confusion over the fact that this is not completely working as expected, so I'll be glad to patiently wait for a fix.

[TonE]

Is it possible already to set the bpm in Reaper via an action? Up to three digits fraction, e.g. 126.012 bpm? That would be great. An action like:

Set tempo to aaaaa.bbb BPM

minimum bpm would be then: 00000.001 bpm
maximum bpm would be then: 99999.999 bpm

Then every user could set a favourite list of bpm values, and switch among those, using actions. Who needs more?

[airon]

Rob Papen Delay x64 - Plugin Crash on project load

It happens only in a specific project, created with an earlier pre-version of 4.23. Here it is.

This crash is consistent, also happens with pre6 but didn't happen with earlier pres(not sure how far back).

Middle of a mix, so I'll have to kill the plugin. Thank god it's not important right now.

Instantiation is fine, but loading the project with the plugin crashes a few seconds after project load. The plugin was working fine. I even installed a slightly updated version of the plugin, just in case.

Problemsignatur:
  Problemereignisname:	APPCRASH
  Anwendungsname:	reaper.exe
  Anwendungsversion:	4.2.2.7
  Anwendungszeitstempel:	4f96f58a
  Fehlermodulname:	RP-Delay.dll
  Fehlermodulversion:	0.1.0.1
  Fehlermodulzeitstempel:	4f855bb5
  Ausnahmecode:	c0000005
  Ausnahmeoffset:	0000000000028413
  Betriebsystemversion:	6.1.7601.2.1.0.256.48
  Gebietsschema-ID:	1031
  Zusatzinformation 1:	556a
  Zusatzinformation 2:	556a8954f6ea2a7c79aa3c05bc45fdcf
  Zusatzinformation 3:	47f2
  Zusatzinformation 4:	47f2609798ad52bf0f0c1c9ddd069546

Lesen Sie unsere Datenschutzbestimmungen online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
  C:\Windows\system32\de-DE\erofflps.txt

[miche]

Originally Posted by schwa

These actions are intended to fix the situation where time is added, removed, or moved within a project. Previously this could result in time signatures that don't make sense. For example, removing one beat from the project could previously could leave behind a measure of 4/4 that is only 3 beats long. Now it should create a new measure of 3/4.

I'll try to test the beta later tonight. If this new function corrects the bug completely, it is going to be a super massive improvement. So thanks a lot for working on this one!

One question though: if I work on a project that was previously bugged out by the old behavior (so there is a weird 4/4 measure stuffed into a 3/4 long measure), what will happen? Will it be corrected? Or will this bugfix only work with actions performed after the installation of 4.23pre7?

[G-Sun]

Originally Posted by schwa

If you set the project timebase to beats, markers should stick to beats rather than time. (This has always been the case -- perhaps I am misunderstanding the report?)

I've been using and testing the tempo and the time-signatures in Reaper a lot, and as far as I know, this is uncorrect.
As it is, tempo-points have time-base set to time, regardless of the project-setting. This is a bug.

Correct behaviour is:
- Tempo-points should always have time-base "beat"
- Time-sigs should always have time-base "beat"

(Just dropping in from holleyday )

I have no oportunity fot testing now, but are thankful for the attention to this, and trusting you guys to get it right.

Rolling, rolling, rolling..

[Banned]

Originally Posted by TonE

Is it possible already to set the bpm in Reaper via an action? Up to three digits fraction, e.g. 126.012 bpm? That would be great. An action like:

Set tempo to aaaaa.bbb BPM

minimum bpm would be then: 00000.001 bpm
maximum bpm would be then: 99999.999 bpm

Then every user could set a favourite list of bpm values, and switch among those, using actions. Who needs more?

Using OSC:

Originally Posted by Default.ReaperOSC

# f: raw floating-point argument. The argument is interpreted directly, to set or
# report a value.

# Example: TEMPO f/tempo/raw
# The device sends /tempo/raw 100.351 to change the REAPER tempo to 100.351 bpm.
# REAPER sends /tempo/raw 120 when the tempo changes to 120 bpm.

It works great (tip: it's pretty easy to make a BPM slider in a Pd patch). But it would be so much better when REAPER would work as expected when changing tempo while playing.

[schwa]

Originally Posted by EvilDragon

So, no changes related to other two problems laid out in THIS thread?

This release is intended to fix (or at least start to fix) both the first and second issues, and part of the third issue. The part of the third issue that is not yet addressed is dragging tempo/time signature markers when individual tempo markers are set to "gradual transition."

I believe that many of the reported problems only exist in the first place, when "gradual transition" is set. It would be useful to focus first on time signature issues that exist when "gradual transition" is not set, if that's possible.

[schwa]

Originally Posted by ovnis

It seems reapers 's dev never work in 3/4 or 5/4. So they dont care about our long time and seriously problem.

Can you be more specific?

[EvilDragon]

Originally Posted by schwa

This release is intended to fix (or at least start to fix) both the first and second issues, and part of the third issue. The part of the third issue that is not yet addressed is dragging tempo/time signature markers when individual tempo markers are set to "gradual transition."

I believe that many of the reported problems only exist in the first place, when "gradual transition" is set. It would be useful to focus first on time signature issues that exist when "gradual transition" is not set, if that's possible.

Thanks for the info, schwa. Sorry if I sounded a bit harsh there, it's just a bit of tough love (and some genunine curiosity)


Let's get the timeline working with timesigs and tempo changes as it's expected to be, then!

[Breeder]

finally!!!

      _____           _____
  ,ad8PPPP88b,     ,d88PPPP8ba,
 d8P"      "Y8b, ,d8P"      "Y8b
dP'           "8a8"           `Yd
8(              "              )8
I8                             8I
 Yb,                         ,dP
  "8a,                     ,a8"
    "8a,                 ,a8"
      "Yba             adP"
        `Y8a         a8P'
          `88,     ,88'
            "8b   d8"  
             "8b d8"  
              `888'
                "

sorry for the spam, couldnt resist the urge

[wolfgerb]

Originally Posted by paterpeter

Ach, wie nur kann ich bloß erziel'n,
dass ich mal wieder Freude hab,
wenn ich versuch was einzuspiel'n,
im MIDI-Modus "overdub"?

Denn wenn ich einmal Noten spiel,
bevor der Schleifenstart erreicht,
bekomm' ich derer viel zu viel,
ich denk' es ist ein Bug vielleicht.

Ist klar, dass ich das tracken ließ
als Bug (ID: vier-null-vier-sechs).
Und dann bei jedem Prerelase,
prüf ich die Changelogs im Reflex.

Doch jedes Mal bin ich enttäuscht,
es ist für mich nichts eingecheckt.
Zumindest nicht das, was ich bräucht':
ein Bugfix für den Code-Defekt.

Drum an den Cockos-Programmeur:
kannst du es arrangieren -
es ist auch sicher nicht zu schwer -
den Bug zu reparieren?

===

Please Cockos, look would you made me do! Have a heart, I beg you!

http://forum.cockos.com/project.php?issueid=4046

very annoying bug indeed!!!
makes time selection autopunch useless in midi overdub mode.

@paterpeter: netter reim;-)

[IXix]

Originally Posted by schwa

It would be useful to focus first on time signature issues that exist when "gradual transition" is not set, if that's possible.

This one's a killer. When you drag the level of multiple tempo points, they need to be automatically repositioned...



In the clip, the points move horizontally slightly as my mouse drifts, which probably shouldn't be allowed. I think dragging multiple tempo points should be automatically constrained to either horizontal or vertical (in which case horizontal movement would be automatically applied by REAPER due to the change in tempo).

To adjust the tempo of the whole project, you have to do each envelope segment individually. You can use the playrate control of course but then you can't easily tell what tempo you're working at. It would be nice if the master bpm and tempo points showed the effective bpm as mutiplied by the playrate.

[Banned]

Originally Posted by IXix

[...] It would be nice if the master bpm and tempo points showed the effective bpm as mutiplied by the playrate.

That would be a great option. +1!

(And thanks for the idea, as this can be implemented externally quite well too. )