LiveSlice 1.47 beta thread

[GilJ]

[LiveSlice v147rc3]

[LiveSlice v147b4]

BR1/ GUI: File browser not being correctly refreshed
1- Maximize the file browser
2- Click on "settings" and set "Number of visible tracks" to 4 for example
3- Click on "settings" again
The file browser is not being correctly displayed

-> Fixed

[LiveSlice v147b4]

BR2/ Switching between Arrangements with LMB while LS is playing = NOK
1- Start host's sequencer
2- Select Arrangement C1
3- Click on Play in Liveslice
4- Select Arrangement C#2
The latter doesn't play! Must select C1 and stop the arrangement, then select C#1 and then click on "Play" again

--> Fixed

[LiveSlice v147b4]

BR3/ Random and strange behavior while resetting an event's parameter with MMB
Since the following feature has been implemented: "you can reset event parameters by dragging over them with middle mouse button down", I have encountered some strange behavior while wanting to reset a parameter for an event with MMB: several events to the left of the selected event parameters' were being reset too (while I wanted to reset only the selected event's parameter!)

--> Seems to have been fixed

[LiveSlice v147b4]

BR4/ Arrangements cells not being refreshed when loop is deleted
1- Load a loop
2- Lock to loop in order to create an Arrangement
3- Delete loop
The arrangement cell still displays the arrangement as not being empty (however, if another arrangement is selected, the all the Arrangements cells are being refreshed)

--> Fixed

[LiveSlice v147b4]

No more able to toggle through predefined default values with RMB on numberboxes
Not a bug, but a very handy behavior that has disappeared
A new feature has been added, which is quite cool (drop down menu on nearly every number box) However, I also found the old behavior while RMB on numberboxes very handy. Wouldn't it be nice if we could have a drop down menu with LMB and cycle through predefined values with RMB for example?

--> Implemented/Fixed

Ohm, thanks for clearing away these B.R
[LiveSlice v147rc1]

However, you have corrected this bug:

[LiveSlice v147b4]
[...]

BR2/ Switching between Arrangements with LMB while LS is playing = NOK
1- Start host's sequencer
2- Select Arrangement C1
3- Click on Play in Liveslice
4- Select Arrangement C#2
The latter doesn't play! Must select C1 and stop the arrangement, then select C#1 and then click on "Play" again

But this one has reappeared instead:

[LiveSlice v145rc3]

BR1/ Changing banks, selects another arrangement
1- Load LS
2- Select arrangement C1
3- Load a loop and lock to loop
4- LMB on LS's "Play" button
5- Start the host's sequencer
6- Select another bank (I.E. bank 2)
C1 arrangement stops to play and C2 gets selected

--> Fixed

Cool

I have been having a strange feeling when using the mouse and clicking on Liveslice's buttons or numberboxes (RMB or LMB) for the last versions of LS.
Have you implemented a sort of "timer" to manage the time it takes to take into account 2 mouse-clicks?

I.E. When I RMB on a numberbox quickly in order to toggle through the predefined values: if I RMB quickly, it won't take into account the 2nd click! I must RMB once, then wait for nearly 1 second in order for the 2nd RMB to be taken into account...
Don't know if I'm clear enough?

I have been annoyed by that as well - it can't be a recent thing, unless windows just recently started working with right mouse double clicks - it's always been like that I think. Thanks to you mentioning double click timers, it just occured to me that the solution would be as simple as handling "right mouse double click" events as well (and treating them as normal right clicks).

So now that problem's gone too

--> Fixed
Very handy now when using rapid double-clicks with RMB
Would it be possible to have the same behavior with LMB please? I.E. Handle "left mouse double click" events as well (and treat them as normal left clicks)


Cheers,
GilJ.

[GilJ]

[LiveSlice v147rc3]

BR1/ No 'submenus' being displayed when clicking on tracks buttons: A, H, D, Pitch, Stretch, Midi1, Midi2

[ohm]

Just been having a look at 147 rc3:
- it looks to me that the "active area" (where clicking will delete the event) has moved to the right. It starts at the middle of the [x] icon and continues past the right-hand side of the icon.

thanks. I moved the active area to where it belongs.

[ohm]

[
Very handy now when using rapid double-clicks with RMB
Would it be possible to have the same behavior with LMB please? I.E. Handle "left mouse double click" events as well (and treat them as normal left clicks)

I just did - works great. Should have thought of that before, certainly speeds things up

[ohm]

[LiveSlice v147rc3]

BR1/ No 'submenus' being displayed when clicking on tracks buttons: A, H, D, Pitch, Stretch, Midi1, Midi2

thanks, fixed.

[JamminFool]

hi,

a very small thing, but i notice that there are problems with the text not quite fitting in the fields in the Setting Page. for example, the "Learn" button, and the "Notes" entry in the "Type" field.

edit: also "Probability Random" in the "Param" field, and possibly others...

also, as a suggestion, perhaps you could fit all the Settings on a single page again (no scrolling). maybe arrange the new expanded "General Configuration" section into two side-by-side columns, or something like that.

great update, btw. thanks!

[DarkStar]

Here's a couple of mine that are now Fixed:

BR 101 - Different tempo displayed (for RX2 files)
BR 099 - Access Violations (none seen in the last few version)

[DarkStar]

BR 105 - High CPU load on redrawing waveforms

OK,
I've done some more testing of the GUI-performance issues that I am having:

• there is a noticeable lag (0.25 second or so) when I load any loop and the waveform is drawn
• the CPU load increases a lot (to >70%) when the Arranger waveforms have to be redrawn, and any changes on the screen become "jumpy"
• for example, dragging the host tempo value to change it causes much recalculation of the waveform display and therefore much CPU load,
• with the GUI positioned so that the waveforms are off-screen, the CPU load still goes high,
• with the LS GUI closed the CPU stays low; when I ramped the tempo from 120 to 150 bpm in the host with LS open, the load was 75%, with LS closed the load was 5%
• selecting "Force GDI" or "fast waveform display" did not affect the CPU load significantly,
• it's the same for me with v145.

Here's a suggestion, as it seems to me that the waveforms are updated (recalculated/redrawn) in "real-time". So:
a) when the LS GUI is moved, there should be no need to recalculate the Arranger and Slicer waveforms at all, only to redraw them in their new positions.
b) when the host tempo is changed, do not recalculate the Arranger waveform displays until the tempo stops changing for a while

That is, in those two cases, only recalculate and redraw the waveform displays when the events triggering the recalc stop or after an interval (this would be a new Setting (from 0 to 1000ms)).

Does that make sense?

[ohm]

well, the waveforms are already precalculated (that's the 0.25 seconds when loading) in 8 different sizes, so the graphics system does not have to work too hard when resizing the bitmaps (it's much faster to resize +-10% than +- 50%).
Nothing is redrawn when the gui is simply moved (it's all buffererd in an offscreen surface).
I can do something about the bpm changes (limit the refresh rate) but other than that... are you 100% sure you can't find some updated graphics drivers? If it's a laptop with ATI or Nvidia graphics it often helps to use some of the unofficial drivers like http://www.omegadrivers.net/ what are the specs again?

I can create a special lofi graphics mode with lower quality bitmaps, and maybe even skip the resizing part completely - that should speed things up for you, but events would not be stretched. I'm 97% sure the stretching is to blame, because that's what separates the events from the rest of the gui.

Actually, on your system, I believe, it might be faster to draw the waveforms in real time, since the bitmap stretching is so painfully slow (sorry). I could look into that - you have been one of the most helpful beta testers since the very beginning so I'm willing to give degree of special treatment Or perhaps you are not the only one? I'm curious, because liveslice performs quite well on all the systems I have access to...

[scuzzphut]

ohm - sorry if this has already been covered -

is it possible to resize the GUI to show more tracks ? I really like the toggle on the browser and wondered if something similar could make the GUI longer (vertically) to show a couple more tracks.

[ohm]

ohm - sorry if this has already been covered -

is it possible to resize the GUI to show more tracks ? I really like the toggle on the browser and wondered if something similar could make the GUI longer (vertically) to show a couple more tracks.

settings: number of visible tracks

[ohm]

about the GUI speed:

it occurred to me that I could simply let the "fast GUI" mode disable stretching of the graphics, and just use some more mipmaps (bitmap buffers) - it works well, and does decrease cpu consumption quite a bit when redrawing events on an old centrino laptop with integrated intel graphics.
I'm finetuning it at the moment. Then there'll be threre GUI options related to speed ! fastest settings are: use alpha [no] show actual duration [no] Fast GUI (lofi) [yes].
The lofi part means that the events will stretch in a more "jumpy" fashion, moving from one pre-scaled bitmap to another.
There's also a speedup loading option that is quite noticable hwn importing longer wave files (they'll loose a bit of the color detail though, but for slower systems it's probably a good setting). Rex import is still rather slow, but I'm mostly relying on the propellerheads library here so I'm not sure there's room for much improvement. I'll check though. I'll have another release candidate ready for the weekend. This time it's really a release candidate... honestly

[scuzzphut]

ohm - sorry if this has already been covered -

is it possible to resize the GUI to show more tracks ? I really like the toggle on the browser and wondered if something similar could make the GUI longer (vertically) to show a couple more tracks.

settings: number of visible tracks

works like a charm

[ohm]

new beta out - fixes the GUI cpu issues (new lofi GUI mode)

[DarkStar]

Me again.

First off, please do not make any special mods _just- for me. That's a kind offer, but I must decline.

Anyway, I think I have narrowed down my problem a bit more - it's caused here by the Alpha setting. I find that with Alpha set ON, the CPU load increases significantly as the host tempo changes, particularly when the host bpm exceeds the event's bpm.

Here's some results for CPU usage:

Code: Select all

		      Ramp 87-99 bpm		Ramp 99-129 bpm
Alpha Off	between 4-6%		between 4-6%
Alpha On	between 7-16%		19 rising to 60%

Also, I could not get "Show Actual Event duration" to do anything. How should I be using it and what should I see?

I have sent a longer explanation in an email.
HTH