liveslice 1.45 beta thread

[CinningBao]

ok do you mean this: you have 8 events in a track and you select the pitch parameter.
Then click on event 5 and drag to the left, over events 4,3,2 and 1.
This is supposed to set the pitch of events 1,2,3,4,5 to values corresponding to the position of the mouse. That's not a bug - it's a feature that enables you to quickly "draw" parameter values.

ah, no. all the parameters to the start of the track are reset to the same parameter - which seems to depend on where the depressed mouse passes over the join between the segments.

[DarkStar]

Me again

[Autostretch] is looking/sounding good (if I stick to [relative] scales for [AHD]).

LS v145b8 Test Report
Fixed BRs:
BR 013 - inserted Event takes parameter values of preceding Event)
BR 075 - Selecting an event highlights the following event temporarily
BR 074 - [Undo] after deleting an event crashes host
BR 073 - MIDI Playback channel out by 1
BR 061 - Default [AHD] values (were not consistent)

Not seen in beta 8, so can tick these as fixed too:
BR 058 - [locate slice] is misbehaving

BRs withdrawn
- as [AHD] proceesing has changed extensively
BR 062 - Changing Absolute <-> Relative changes waveforms
BR 056 - the [A], [H] and [D] parameters

New BRs:
BR084 - [Reset] sets wrong [D] value
- when you insert an Event, the default [AHD] values are 0% 95% and 5%
- if you [Reset] the event, the [AHD] values are 0% 95% and 3%

BR083 - Events triggered by too many MIDi notes
- create an Arranger track with 5 events in it
- set MIDI playback Play Slices to Channel [1] notes [C6] .. [[B7], use Arrangement [E1]
- trigger the events from your MIDI keyboard
=> keys C6 to E6 trigger the correct events
=> keys F6 to A#7 wrongly trigger the fifth event too.

BR082 - [H] mode setting affects inserted events
- create two tracks
- select [H] on each
- set [H] mode on the second track to Absolute
- [lock to loop] on each track to add the same loop to each
Notice the quite different displays

- Ctrl+a on each track to select all events
Check out the [H] values
-all at 95% on the first track, but all set to 95ms on the second track.

- change [H] mode on the second track to Relative again
-the [H] values are all different percentages [see the third track in the screenshot]


big pic: http://img267.imageshack.us/img267/9170/lsbr082ch8.png


It looks to me that Absolute and Relative [AHD] values are getting mixed up.

BR081 - Changing [H] scale to [Absolute] messes up [Autostretch]
- add an event
- click [Autostretch]
The event will be stretched suitably
- select [H]
- change its scale to Absolute
=> the stretching is undone

- now drag the [H] scale upwards
=> the [H] value will change (I think this is because it is held internally as a % of the scale).

BR080 -Open LS GUI uses up much CPU
- with LS closed and being triggered, rapid mouse movements increase the CPU to 8%
- with LS open and being triggered, rapid mouse movements increase the CPU to 70%, even though no graphics on LS were being updated

BR079 - Slow arrows keys for selecting next/previous event
These seemed a bit slow (depending on amount of graphics displayed in the track?)

Also, the delay before the action repeats was too long (for me). Can the Windows Mouse settings be used?

BR078 - Zoomed-in scroll speed
- When zoomed right-in, dragging the scroll bar to scroll is quick.
- but at lower zoom levels (e.g. so that half the loop is displayed), there is a noticeable delay when dragging the scroll bar

BR077 - Blocky graphics in Arranger
- With Arranger tracks of 4 beats, the waveforms' graphics are blocky
[admittedly, this was seen for melodic loops, not percussion, but even so]

BR076 - Decreasing [A] does not increase [H]
- holding down both mouse buttons while dragging [A] downwards does not increase the [H] value (but holding down both mouse buttons while dragging[A] upwards does decrease the [H] value)

Also, holding down both mouse buttons while dragging [A] is awkward - can we have alternative (Alt+drag perhaps)

HTH !

[GilJ]

But when I record a loop, there are lots of glitches and the waveform isn't displayed on the track (it even made Live crash one time ) I must refresh the GUI (by selecting another arrangement or closing/reopeing LS) in order to see the waveform on the track and hear correctly the loop again.

fixed, the slices were not properly updated when the recording was ended and saved, causing glitches in playback. I'm not sure if I should fix this bug or just start marketing liveslice as a plugin "made especially for glitch and IDM" - sounded kinda cool actually (if glitch is still cool, I dunno, I might be a bit out of the loop, pun intended)

[LiveSlice v145b8]
BR1/ Problem with the 'clear' function
If I 'clear' all, arrangements or loops, LS then behaves abnormally (wrong display etc.), it even made Live crashed a couple of times...

BR2/ Strange display of events' waveform
1- Create an event on a track (at the beginning of the track; the size of the event should be roughly a quarter of the size of a track in order for the problem to be easily identified)
2- Select the event and drag it to the right of the track (or drag it to the last grid of the track)
The waveform of the event is being changed the more the latter is being moved towards the end of the track (I.E. the same event is being displayed differently if it is placed on the first grid or the last grid of a track)

[CinningBao]

ok do you mean this: you have 8 events in a track and you select the pitch parameter.
Then click on event 5 and drag to the left, over events 4,3,2 and 1.
This is supposed to set the pitch of events 1,2,3,4,5 to values corresponding to the position of the mouse. That's not a bug - it's a feature that enables you to quickly "draw" parameter values.

ah, no. all the parameters to the start of the track are reset to the same parameter - which seems to depend on where the depressed mouse passes over the join between the segments.

ok, i managed to capture the visual side of what's going on regarding this bug, there's a folder here with an html file and an swf - if you download them, make sure they're in the same directory, and run the html file it will display the shockwave video file - sorry about this, it's the cheapest (free) way i could find of capturing it and showing you.. i hope it is of some use!

http://www.box.net/shared/q6p1omfpcp

[DarkStar]

[LiveSlice v145b8]
BR1/ Problem with the 'clear' function
BR2/ Strange display of events' waveform

These are both Ok here - didn't use Live though, used eXT and Tracktion

[GilJ]

[LiveSlice v145b8]
BR1/ Problem with the 'clear' function
BR2/ Strange display of events' waveform

These are both Ok here - didn't use Live though, used eXT and Tracktion

Thanks for the tests DarkStar

However I've tested these 2 BRs on 2 different computers, and I'm having the same behavior...
Just tested with eXT + LiveSlice, and I'm also having the reported bugs
Can anyone else please confirm (or not) these 2 BRs ?

Cheers,
GilJ.

[ohm]

[LiveSlice v145b8]
BR1/ Problem with the 'clear' function
BR2/ Strange display of events' waveform

These are both Ok here - didn't use Live though, used eXT and Tracktion

Thanks for the tests DarkStar

However I've tested these 2 BRs on 2 different computers, and I'm having the same behavior...
Just tested with eXT + LiveSlice, and I'm also having the reported bugs
Can anyone else please confirm (or not) these 2 BRs ?

Cheers,
GilJ.

If the events are very long and you drag then to the right (so they are dragged outside the track boundaries), there's a bug in beta 8 causing the wrong bitmap to be used for display. result: the image is "blocky" - This bug has been fixed. Optimizing a complex GUI like the one in liveslice is not an easy task

[ohm]

Confirmed and fixed GilJ's problem with "clear" funtion. It crashed the host when you did a clear all and the arrangement was playing. Also forced an update of the arranger window - somehow it was not redrawn properly.

[GilJ]

Thanks Ohm, I think that LS v1.45 gonna be one of the best, rock solid versions of LS

[ohm]

BR084 - [Reset] sets wrong [D] value

fixed

BR083 - Events triggered by too many MIDi notes

fixed - now you can trigger multiple tracks if you hit a midi not outside the range of the first track, you move on to the next tracks.

BR082 - [H] mode setting affects inserted events

fixed

BR081 - Changing [H] scale to [Absolute] messes up [Autostretch]

You are right - the duration should always remain the same when you change from relative to absolute and vice versa.
It doesn't make sense though to use autostretch if the volume envelope is set to absolute values. It is techically possible, but would require the max-duration to be re-calculated, so the values wouldn't be "absolute" anymore, they'd be relative, but labeled as absolute.
So anyways: here's what I'll do: if autostretch / autopitch is active and you change the decay from relative to absolute, the values are re-calculated to maintain the same duration, and autostretch is de-activated.
Additionally if the volume envelope is in absolute values and you hit "autostretch", the envelopes are set to "relative".

BR080 -Open LS GUI uses up much CPU

I can't reproduce, but I think I have an idea as to what could be causing this behavior on some systems. I've tried disabeling the mouse-over features on the "numberbox" controls - hardly needed anyways and they did seem to use a bit of CPU. Since I can't reproduce, some more info would be helpfull. For instance: what if you don't move the mouse? does the CPU still go high? Is it the same in all hosts? It's odd, cause here I'm safely below 10% (and my CPU is a humble AMD643200+ not even dual core) unless I start creating real complex arrangements with 70+ events and 4+ tracks - there's still room for some optimization for really large arrangements I think. What is your graphics card again? Updated driver etc. etc. right?

BR079 - Slow arrows keys for selecting next/previous event
BR078 - Zoomed-in scroll speed

probably both are related to the above CPU issue - should not be present in next beta

BR077 - Blocky graphics in Arranger

fixed

BR076 - Decreasing [A] does not increase [H]
- holding down both mouse buttons while dragging [A] downwards does not increase the [H] value (but holding down both mouse buttons while dragging[A] upwards does decrease the [H] value)

I'm not sure the values should automatically increase. I mean what if you wanted to set all three params to 10% relative? then it wouldn't work if the sum was always forced to 100%. One solution would be to remember the last position set with the mouse, so that if you have AHD = 20%, 50%, 30%, then set A to 60% (H lowered to 10%) and then set A to 10%, the H parameter would be increased to 50% but not 60%, because 50% was the last value chosen by the user. Complicated but probably the smoothest solution for the user.

Also, holding down both mouse buttons while dragging [A] is awkward - can we have alternative (Alt+drag perhaps)

right now you hold both mouse buttons to prevent the automatic changing of parameters (in beta 7 it was the other way around) but if you want Alt+drag, you got it

thanks for the extensive list, it was very helpful.

[DarkStar]

thanks for the extensive list, it was very helpful.

We aim to please.

Thank you for the fixes - triggering multiple tracks
- deactivating [Autostretch] if you switch to [Absolute] sounds Ok
- on switching from [Absolute] to [Relative} or vice versa when you recalculate the values please adjust the parameter levels and scales suitably.

- CPU usage, with LS being triggered by host and "hands off" (i.e. no mouse movements)
- with LS closed, CPU varies between 8-11%
- with LS open, CPU varies between 29-41%
- processor used: AMD XP 2600+, graphics Radeon 9500 (not the latest drivers, but no problems with other s/w)

- yep, I understand about not forcing the sum of [AHD] to 100%. So I withdraw that BR !

- thanks for saving my fingers from complex mouse-button presses. I need my hands to type Test Reports (and I have a load of FRs stashed away too).

Confirmed and fixed GilJ's problem with "clear" funtion. It crashed the host when you did a clear all and the arrangement was playing. Also forced an update of the arranger window - somehow it was not redrawn properly.

Ah ha, I wasn't playing any arrangment in my test.

PS - Q 009: What determines how much stretching [Autostretch] does?

[CinningBao]

Beta8 BR 0B - Gui gives up at 700+ bpm

load a sample, add to track, trigger arrangement, up tempo to 700+ - gui stops responding.

i may be one of the few users who exceeds 700bpm, but a fix would still be hugely appreciated.

have you had any luck recreating BR 079?

[ohm]

Beta8 BR 0B - Gui gives up at 700+ bpm

load a sample, add to track, trigger arrangement, up tempo to 700+ - gui stops responding.

i may be one of the few users who exceeds 700bpm, but a fix would still be hugely appreciated.

have you had any luck recreating BR 079?

What host are you using - I've tried energy xt (running fine at a max of 250bpm), Jeskola Buzz (500 bpm max, no problems) what host can go to 700 bmp?? Also: does this happen every time? What if you set the bpm with no playback does it crash on start?
I think I have fixed the other bug you mentioned, but it's very hard to reproduce reliably so I'm not 100% - try the next beta, and see if it persists.

[CinningBao]

What host are you using - I've tried energy xt (running fine at a max of 250bpm), Jeskola Buzz (500 bpm max, no problems) what host can go to 700 bmp?? Also: does this happen every time? What if you set the bpm with no playback does it crash on start?

Live goes up to 999, Logic can go up to 9999(!), PlogueBidule can go infinitely fast. Not sure about the Steinberg range.. Yeah this happens everytime, and it also crashes if I slide above that 700-750 range without the host running - the gui stops updating and I have to restart it.

I think I have fixed the other bug you mentioned, but it's very hard to reproduce reliably so I'm not 100% - try the next beta, and see if it persists.

Good work can't wait!

[soma]

Pardon my ignorace, but can I give B9 a whack when it drops?