LiveSlice 1.47 beta thread

[ohm]

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

Cheers,
GilJ.

thanks, yeahm that's odd. I can't think of why I would ever have wanted the selected arrangement to change when you clicked the bank tabs, but the code was right there: change bank, and the arrangement would change... must have been one of those late night coding sessions. All fixed now anyways

[GilJ]

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?

[ohm]

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

[GilJ]

[...]
So now that problem's gone too

Great
Waiting for LiveSlice v147rc2 then

[ohm]

Can anyone replicate this bug?
In latest version of REAPER (2104), open LiveSlice 1.47 beta 3 in a track, then load a bank using REAPER's native patch loading function. The first bank loads flawlessly. But when trying to load another bank in same LiveSlice, it crashes REAPER.
Is this REAPER or LiveSlice at fault?

I'm pretty sure this has finally been fixed (and bank loading is faster now too ) I'll send out a new beta when I've looked at the note labeling differences in reaper, xt and logic 5.

I also adressed the issue with rx2 tempos: now both the defined and the calculated tempos are displayed (so a stretched 120bpm will display something like "120 (86.5) bpm" )

[audio_dude]

Hi ohm,

this bug still happens with RC1 (host is latest FL) :

using a correct MIDI config, and the Piano Roll, I actually succeeded in triggering my slices from the host , but as soon as I went back to the LiveSlice GUI, my current selected loop was immediately replaced by the very last entry in the "Loops" list (and it was actually an empty entry !).

The result was there were no more sound coming from LiveSlice since the "sel. loop" was the option I chose in the "settings" tab, and the selected loop was now set to "empty".

Anyone can confirm this bug ?

Thanks !

sounds like you have a midi note configured to trigger the selected loop - check the midi controller configuration in "settings".

Thank you, ohm, you were right !

Now, I think it's time to "Liveslice" and make some noise

[DarkStar]

I don't think this is me, but ...

LS seems a bit "sticky" - for example, moving the GUI around the screen uses up a lot of CPU and the GUI jumps rather than moving smoothly. I don't get this with otherb VSTs. But even loading a single loop takes a noticeable time.

I guess there's a lot of redrawing going on but I am noticing it more with these recent versions.

[Former Pharaoh]

I don't think this is me, but ...

LS seems a bit "sticky" - for example, moving the GUI around the screen uses up a lot of CPU and the GUI jumps rather than moving smoothly. I don't get this with otherb VSTs. But even loading a single loop takes a noticeable time.

I guess there's a lot of redrawing going on but I am noticing it more with these recent versions.

Absolutely. I never mentioned anything because i figured it would get remedied as newer versions come out (i believe the last version that worked smoothly for me was 1.44).

[ohm]

I made some improvements that could be very noticable on older systems, and added a new option to force the rendering to use GDI - could help those of you who experience a sluggish gui. On my system the LiveSlice GUI is now one of the fastest... at least when it comes to grabbing and dragging the window around while watching the CPU cunsumption of the host process in the process explorer. Most windows use quite a bit of CPU when dragged btw.

P.S. I also improved the quality and rendering time of the coloured waveform display

[GilJ]

[...]
On my system the LiveSlice GUI is now one of the fastest...
[...]
P.S. I also improved the quality and rendering time of the coloured waveform display

[ohm]

Hi Testers

New version in the inboxes

Here we are at RC 3 and I have added new features... I guess that's against the convention, but who cares - liveslice is much better now.

I've been working hard on this update - I was able to reproduce the GUI slowdowns people have been complaining about on an old laptop with integrated graphics. So the last couple of days, I've been busy optimizing and fixing the GUI.

Another major update is the new improved waveform display. It now displays both the loudest and the average frequency at each pixel, so if you have a bassdrum with a hihat, both components are usually visible. I also smoothed the display a bit.

There's an option in settings to activate a less fancy, but very fast rendering mode - it's less accurate and not as pretty of course.

[sinkmusic]

Thank you very much, Ohm.

[scuzzphut]

ohm - your continued development of Liveslice is hugely appreciated here

[GLT]

Hi Ohm,

thank you for the good work!!!
Did you get my request to be added to the beta testers?

cheers

glt

[DarkStar]

Just one I've noticed for the moment:

[BR 102] The active area [x] for deleting an event seems to have got smaller or not working correctly. Sometimes it takes me 4-5 clicks in the right position to delete the event.

Will test more later. .

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.

HTH

Will try the graphics performance changes later.