Bitwig Studio 1.3.8 RC-1

[takaii]

Haha, really nice:

Cut notes at end of clip.PNG

didn't noticed that before. Is it since this RC?

Yes we now show visual indications for notes that are truncated. This also helps to understand playback of the notes as a note can start in one clip and continue in another clip (e.g if you use the knife tool on a clip that splits a note in half)

hi nick you wrote you had a fix in a earlier rc1 1.3.x of something with a fix for slow midi when you have a lot of midi information on a track. How has it been going with that? need more testing before releasing out?

[takaii]

Bug with loop if you set start up different than loop start. BUt loop end with clip length end the midi wont loop within bitwig 1.3.8 rc

loop.png

[nickallen]

Visual bug: notes hanging out of the arranger clips and waveforms are not right either.
(Windows 10)

I can't reproduce this. Would you be able to make a minimal project with just one track and clip that shows this problem and send it to me (PM or as attachment)?

[nickallen]

Bug with loop if you set start up different than loop start. BUt loop end with clip length end the midi wont loop within bitwig 1.3.8 rc

loop.png

That is the correct behaviour. The loop start is in the middle of the note so there is no note on when the loop goes back. If you want a long note that goes through the loop just extend the end of the note beyond the loop end. That way the note will play as long as the clip is playing.

[nickallen]

Haha, really nice:

Cut notes at end of clip.PNG

didn't noticed that before. Is it since this RC?

Yes we now show visual indications for notes that are truncated. This also helps to understand playback of the notes as a note can start in one clip and continue in another clip (e.g if you use the knife tool on a clip that splits a note in half)

hi nick you wrote you had a fix in a earlier rc1 1.3.x of something with a fix for slow midi when you have a lot of midi information on a track. How has it been going with that? need more testing before releasing out?

We're still working on that fix but it will hopefully make it into the 1.3.9 version.

[nickallen]

Yes!! More stability improvements.

It's not clear from the bug fix list, but did the bug where plugins reset to default state on crashes get fixed yet?

If there is a crash we cannot restore absolutely everything. Well we can for Bitwig native devices but for plugins we are backing up their state every 5 seconds as long as transport is not playing (as asking plugins to save during playback could cause performance problems or audio glitches). So if you are constantly playing the arranger and never stopping transport for more than 5 seconds the plugin's state will not be backed up. The correct way to fix this problem is not to crash of course!

[takaii]

Haha, really nice:

Cut notes at end of clip.PNG

didn't noticed that before. Is it since this RC?

Yes we now show visual indications for notes that are truncated. This also helps to understand playback of the notes as a note can start in one clip and continue in another clip (e.g if you use the knife tool on a clip that splits a note in half)

hi nick you wrote you had a fix in a earlier rc1 1.3.x of something with a fix for slow midi when you have a lot of midi information on a track. How has it been going with that? need more testing before releasing out?

We're still working on that fix but it will hopefully make it into the 1.3.9 version.

Take time needed, so there dont have to be a fix for a fix

[takaii]

Bug with loop if you set start up different than loop start. BUt loop end with clip length end the midi wont loop within bitwig 1.3.8 rc

loop.png

That is the correct behaviour. The loop start is in the middle of the note so there is no note on when the loop goes back. If you want a long note that goes through the loop just extend the end of the note beyond the loop end. That way the note will play as long as the clip is playing.

haha was about to write a mail about it. good to know =)

[nickallen]

Bug with loop if you set start up different than loop start. BUt loop end with clip length end the midi wont loop within bitwig 1.3.8 rc

loop.png

Actually if I recreate this same setup the note plays forever but it should only play in the first loop not subsequent loops (unless the note hangs out over the loop end) so there is definitely a bug there.

[takaii]

Bug with loop if you set start up different than loop start. BUt loop end with clip length end the midi wont loop within bitwig 1.3.8 rc

loop.png

Actually if I recreate this same setup the note plays forever but it should only play in the first loop not subsequent loops (unless the note hangs out over the loop end) so there is definitely a bug there.

Yeah had same issue (y)

[u-u-u]

Haha, really nice:
Cut notes at end of clip.PNG

didn't noticed that before. Is it since this RC?

Yes we now show visual indications for notes that are truncated. This also helps to understand playback of the notes as a note can start in one clip and continue in another clip (e.g if you use the knife tool on a clip that splits a note in half)

Yeah, that's awesome. Using note clips as switches between different automation envelopes/loops without retriggering the note came to my mind. Was possible before I think but can really see what's going on now:

No note retriggering.PNG

And consolidated...perfect:

consolidated.PNG

Maybe even more powerful in clip launcher

[codec17]

Yes!! More stability improvements.

It's not clear from the bug fix list, but did the bug where plugins reset to default state on crashes get fixed yet?

If there is a crash we cannot restore absolutely everything. Well we can for Bitwig native devices but for plugins we are backing up their state every 5 seconds as long as transport is not playing (as asking plugins to save during playback could cause performance problems or audio glitches). So if you are constantly playing the arranger and never stopping transport for more than 5 seconds the plugin's state will not be backed up. The correct way to fix this problem is not to crash of course!

That is a really interesting piece of text there nickallen.
Thnx... sometimes slap the spacebar and leave it for 5secs.
(When heavy editing of course )

[Ogopogo]

Yes!! More stability improvements.

It's not clear from the bug fix list, but did the bug where plugins reset to default state on crashes get fixed yet?

If there is a crash we cannot restore absolutely everything. Well we can for Bitwig native devices but for plugins we are backing up their state every 5 seconds as long as transport is not playing (as asking plugins to save during playback could cause performance problems or audio glitches). So if you are constantly playing the arranger and never stopping transport for more than 5 seconds the plugin's state will not be backed up. The correct way to fix this problem is not to crash of course!

That is a really interesting piece of text there nickallen.
Thnx... sometimes slap the spacebar and leave it for 5secs.
(When heavy editing of course )

You could just hit ctrl+s instead of waiting the 5 seconds, right?

[codec17]

Well yes but no, sometimes i dont want to save it as a project... but just working on cutting beats,basslines,fx etc, and drag them as clips into my browser for later use. In that way i dont end up with a bunch of projects i wont open anymore.
(yes i know you can drag certain tracks of a project from browser to working project , but i like it sorted)

[u-u-u]

(yes i know you can drag certain tracks of a project from browser to working project , but i like it sorted)

Sry, for being off-topic but just tried that again. Drag tracks and sends in from another project simultaneously and it will even restore send routing+automation of these tracks! Very cool indeed
OK, it's probably the same as having that project open in another tab and drag tracks over. very great nevertheless...
off-topic: off