1.843

[Diogenes]

New build! 1.843

In true JBM fashion...

In 1843 Queen Victoria visits France in September and meets with King Louis Philippe. (Where they got soused and got jiggy widdit!)



D

[ten]

She kicked his arse, actually

Whats new in 1.843 then... ?

tom

[Diogenes]

Originally Posted by ten

She kicked his arse, actually

Whats new in 1.843 then... ?

tom

Bah... I like my version better!

* new default option to use the same file for looped recording
* fixes to varispeed loop recording and autopunch recording
* prefixing + or - in Ctrl+J dialog moves relative
* better docked/undocked transport sizing
* new dither_psycho (thanks schwa)
* ASIO: support for type 27 (32/24 bit) PCM samples
* ReaEQ: fixed combobox changing during automation issue
* ReaComp: default RMS size is now 5ms, to reduce distortion, updated ui for AA/limiting
* ReaInsert: MIDI channel options
* ReaNINJAM: revamped reaper-ish UI, better show button behavior
* ReaNINJAM: remote channels now default to -12dB

Just grabbed it myself...

D

[ten]

BIG personal thanks for midi chans on ReaInsert. Having this is better than a years supply of morning after contraception pills!

tom

[Youn]

I'm too lazy to figure this out: what does midi chan reainsert do?

[Youn]

ok, wait, nevermind.... yeah the midi options are definately cool

[Bevosss]

With the new + and - options in the jump to time window, we can now move forward or backward X number of bars. So if you have auto hot keys or an n52, you can now make up macros for jumping a bar and slicing/pasting/deleting , whatever. If you don't, you'll still have to use the mouse for now.

I'd still like to see the fast forward and rewind snap to the grid (instead of 6 beats at present), seems the easiest useful method for making up complex macros that require navigation.

[xackley]

* new default option to use the same file for looped recording

I haven't thoroughly tested it, but I may have to give up 3 boxes of cheap red wine, and buy reaper.

I Ctrldragged the takes and glued Take 1 and Take 2 end to end, and the alignment at the crossover was beatiful.

Takes can now be dragged at the ends, revealing the sound in the next/prev take.

This appears to be a very workable resolution to Losing the end of each take problem, and creates new mixing options.

FR:
Take menu\Spit Takes to Clips.
and/Or
Automaticly split if the user has Item Property\Looped enabled.

With exploding and gluing, there are already workarounds. I work at the verse level, but for someone working at Beat level, they might want a default to split to clips at the end of the loop recording.

Thank you
Don

[Jae.Thomas]

Originally Posted by ten

BIG personal thanks for midi chans on ReaInsert. Having this is better than a years supply of morning after contraception pills!

tom

...as long as you dont take em all at once

heh

[bullshark]

Can somebody explain to me what "new default option to use the same file for looped recording" means please?

[xackley]

In Preferences\Recording there is now an option "create new files on Loop"

When checked, Reaper Loop records as it always has. The down side was that the Takes never reached the End of the Loop area, alway short. There are half a dozen bug reports describing the problem in different ways.

Now the default is the program record 1 file and displayes it as Takes. All the takes now fill the entire loop area. No lost data at the end of every Take.

IOW, it is a good thing. Test turning the option off and on thru a few loop recordings to see and hear the difference.

[Bevosss]

Originally Posted by xackley

Takes can now be dragged at the ends, revealing the sound in the next/prev take.

How do you drag the takes out to their full combined length? I've tried for ages now and all I get is the selected take looped, not the continuous file I expected. Any ideas?

[aldi]

great things in there thx a lot. it's getting better with every update or with other words every day

[xackley]

Originally Posted by Bevosss

How do you drag the takes out to their full combined length? I've tried for ages now and all I get is the selected take looped, not the continuous file I expected. Any ideas?

It just happens now, Loop Record 4 Takes, put the cursor at the beginning or end of Take 2, Drag.

[bullshark]

Thanks for the explanation xackley.

[beatbybit]

you sholud read this :

http://www.cockos.com/forum/showpost...5&postcount=12

confirmed here. (612 samples at 1024 buffer size)

[Bevosss]

Originally Posted by xackley

It just happens now, Loop Record 4 Takes, put the cursor at the beginning or end of Take 2, Drag.

Well it works now! Not sure why it didn't before, but thanks for the clarification xackley.

[xackley]

Originally Posted by beatbybit

you sholud read this :

http://www.cockos.com/forum/showpost...5&postcount=12

confirmed here. (612 samples at 1024 buffer size)

confirmed, the Takes are early.

[Justin]

Originally Posted by xackley

confirmed, the Takes are early.

Are they early, or is the extended version late? I'm pretty sure it is the latter (from both the following explanation as well as empirical tests), as a result of the loop length of playback/recording being quantized to the ASIO blocksize...

[xackley]

How about Take 1 is late, and Take 2,3,4... on time.

Having Take 1 late is scarier than having the other takes early.

I can't tell from your response if it is something you feel needs fixed. The wave form should be consistent between all takes?

[Justin]

Originally Posted by xackley

How about Take 1 is late, and Take 2,3,4... on time.

Having Take 1 late is scarier than having the other takes early.

I can't tell from your response if it is something you feel needs fixed. The wave form should be consistent between all takes?

All of the takes are on time, as they are inserted into the project.

The problem is that when you extent take one out, take two starts "later" after because there are samples in between take one and take two that are recorded.

If you try recording a click looped, you will see they all match (if you switch between takes or view lanes).

The real problem is the way REAPER loops playback (being block-granular). This has been an issue for a long time, but I'm ready to revisit it so there's a chance it'll be resolved once and for all soon.

-Justin

[Bevosss]

Originally Posted by Justin

The real problem is the way REAPER loops playback (being block-granular). This has been an issue for a long time, but I'm ready to revisit it so there's a chance it'll be resolved once and for all soon.

Yayyy! That should get rid of the end glitch when looping.

[Jonas_Eriksson_Swe]

* new default option to use the same file for looped recording

great! this is really useful when compiling takes that was recorded in a loop and one of the takes turned out longer than the loop. thanks a bunch!

regards,
- Jonas

[Tallisman]

* new default option to use the same file for looped recording
* fixes to varispeed loop recording and autopunch recording
* prefixing + or - in Ctrl+J dialog moves relative
* better docked/undocked transport sizing
* new dither_psycho (thanks schwa)
* ASIO: support for type 27 (32/24 bit) PCM samples
* ReaEQ: fixed combobox changing during automation issue
* ReaComp: default RMS size is now 5ms, to reduce distortion, updated ui for AA/limiting
* ReaInsert: MIDI channel options
* ReaNINJAM: revamped reaper-ish UI, better show button behavior
* ReaNINJAM: remote channels now default to -12dB

brilliant update!

[Tallisman]

* ReaNINJAM: revamped reaper-ish UI, better show button behavior
* ReaNINJAM: remote channels now default to -12dB

these are huge improvements! Really. ninjam is killer and this new UI revamp just makes better sense.

OT:
I have a pal in Singapore who is having difficulties connecting to ninjam... he keeps getting dumped from the server, audio quality is terrible for him, and he often sounds chipmunkish? any ideas on what might be happening?

He downloaded the latest m-audio driver for his i/o card and that seems to have cleared the chipmunk stuff.

what is the min required bandwidth? the odd thins is yesterday, it worked fine.

cheers,

[Bubbagump]

i haven't played with NinJAM yet, but is it good enough to be able to track things remotely? As in have someone in a studio in place A and record to DAW in place B and still maintain quality? I know in reading the regular NinJam docs that it uses Ogg, so i assume this is the same deal thus not really for recording.

[Justin]

Here's a test for you guys.. should loop sample-accurate.

http://www.reaper.fm/files/reaper1843_newloop1.zip

Record-output modes may lose sync slightly after looping.. but you guys can test a lot of this. I mostly just tested playback and record input mode.



-Justin

[beatbybit]

wow Justin,

here's a quick (and selfish..) test-result:

it seems to be ok now. tested in 174bpm, one bar, 6-7 takes.
i get 1-2 sample difference - i think it's due to the samplerate and the chosen tempo. (am i wrong?)

recording the track out - with a ReaEQ tweaking around "live" - looks good too, at the 7th take i have about 3 samples difference.


does it make any sense to let the cursor move at sample-level-zoom setting only by sample, not by pixel? i think it would be better, than having a chance to "split one sample"

it'd be good for sample-accurate editing, and for measuring, imho.



oh, and THANK YOU, again.

[Justin]

Originally Posted by beatbybit

wow Justin,

here's a quick (and selfish..) test-result:

it seems to be ok now. tested in 174bpm, one bar, 6-7 takes.
i get 1-2 sample difference - i think it's due to the samplerate and the chosen tempo. (am i wrong?)

recording the track out - with a ReaEQ tweaking around "live" - looks good too, at the 7th take i have about 3 samples difference.


does it make any sense to let the cursor move at sample-level-zoom setting only by sample, not by pixel? i think it would be better, than having a chance to "split one sample"

it'd be good for sample-accurate editing, and for measuring, imho.



oh, and THANK YOU, again.

I'll try more odd bpm sizes/etc to test.. but in general if it's within a couple of samples, I'm psyched about it.

as far as having the cursor only able to move to each sample, the real problem is that the rate of different items can differ... but I guess one could use the project rate for that. but I like it the way it is now (sort of subsample accurate).

-Justin

[beatbybit]

Originally Posted by Justin

as far as having the cursor only able to move to each sample, the real problem is that the rate of different items can differ... but I guess one could use the project rate for that. but I like it the way it is now (sort of subsample accurate).

-Justin

i meant by project sample rate, but geez.. different sample rates, right, right..

i can live with this, happily.


(should i ask here for ALT+Drag to "slip-slide", not SHIFT+ALT+Drag, please?..)

[Justin]

Originally Posted by beatbybit

i meant by project sample rate, but geez.. different sample rates, right, right..

i can live with this, happily.


(should i ask here for ALT+Drag to "slip-slide", not SHIFT+ALT+Drag, please?..)

At some point we'll make these modes configurable... i.e. "modifiers for slip: [x][x][x]" "modifiers for shuffle: [x][x][x]" ...

[Tallisman]

I agree the sub sample accurate is killer. Tha traised a huge grin on the collective face of cubase users when it was introduced.

Originally Posted by Justin

I'll try more odd bpm sizes/etc to test.. but in general if it's within a couple of samples, I'm psyched about it.

as far as having the cursor only able to move to each sample, the real problem is that the rate of different items can differ... but I guess one could use the project rate for that. but I like it the way it is now (sort of subsample accurate).

-Justin

[beatbybit]

Originally Posted by Justin

At some point we'll make these modes configurable... i.e. "modifiers for slip: [x][x][x]" "modifiers for shuffle: [x][x][x]" ...

you're the men.


LoopRec works OK at different tempos here.

[Tallisman]

Justin, how deep do you think you'll take this configuring modifiers thing? any chance to open up the whole mouse paradigm?

Originally Posted by Justin

At some point we'll make these modes configurable... i.e. "modifiers for slip: [x][x][x]" "modifiers for shuffle: [x][x][x]" ...

[Bubbagump]

Err, what in the world is this loop record stuff you fellers are referring to?

[Tallisman]

Justin, how deep do you think you'll take this configuring modifiers thing? any chance to open up the whole mouse paradigm?

Originally Posted by Justin

At some point we'll make these modes configurable... i.e. "modifiers for slip: [x][x][x]" "modifiers for shuffle: [x][x][x]" ...

[Justin]

This one should be slightly more accurate (in looping):

http://reaper.fm/files/reaper1843_newloop2.zip

[beatbybit]

well,

i f did everithing right (hope i did) :

128 bpm, 11 takes. at the 37th second the difference is about 9 samples. (the takes are late to the extended version)

i think the previous build was more accurate.


while recording - the selected area is sometimes "filled" to the whole selection (good), but sometimes (some takes) has a little "graphical gap".
this is really just a cosmetic thing.

is there anything more to focus on in this build/version? (about LoopRec)

[Justin]

Originally Posted by beatbybit

well,

i f did everithing right (hope i did) :

128 bpm, 11 takes. at the 37th second the difference is about 9 samples.

i think the previous build was more accurate.

Can you test the previous build in the exact same situation and compare?

As far as other testing, just testing looped playback (with latent fx especially), loopskip playback mode, smoothseek, project looping, too, would be good..

oh and doing all of that with and without varispeed, too.

Oh and test the different record modes (midi ones especially), and also record output (which may have length issues when recording loops, i.e. you might see an extra bit of data in the wav file, although the takes should be trimmed properly).



-Justin

[xackley]

Take 2 is 1 sample later than take 1 stretched
Take 3 is 2 samples later than take 1 stretched
Take 4 is 3 samples later than take 1 stretched.

Recording at ASIO 20ms, 44.1

I don't think there is any possibility I can hear the difference