liveslice 1.45 beta thread
-
Former Pharaoh Former Pharaoh https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=124033
- KVRian
- 520 posts since 13 Oct, 2006
I'm better than you. Deal with it.
-
- KVRist
- 107 posts since 4 Mar, 2003 from Herts. UK
Thanks Jon - OK this time
-
- KVRAF
- 10366 posts since 2 Sep, 2003 from Surrey, UK
[Using LS 145 beta 3]
BR 043 - last inserted event moves when you click
After inserting an event, when you select another slice the event moves to be aligned vertically to wherever you click the mouse in the Slicer (or even in the empty space below the track)
BR 044 - Parameter value stops changing
Changing a parameter value stops if you move the mouse too far above or below the track (also occurs in v1.4.4)
BR 045 Overlapping events
When a short event starts and ends within another longer event you do not get the delete [x] icon in the top-right corner for the longer event
BR 046 - Slow response times- heavy CPU usage
- the mouse response stutters and LS is slow to respond when, for example, clicking Parameter buttons or moving parameters
- playback uses 100% CPU
BR 047 - gaps between events
- When you [Lock to loop] to insert a loop into a track each event is slightly wrong
- there is a visible and audible gap between each event. See this:

Big pic:
http://img440.imageshack.us/img440/1787/lsbr047vt8.png
BR 048 - wrong cursors
I get the wrong cursor at various times, e.g the text editing cursor is kept _after_ I have completed editing a loop name, or the double-headed arrow <-->-is kept after I had done some slicing and moved over the function buttons.
BR 049 - crashes when you stop playing an empty Arrangement
- open LS
- click [Play] - runs OK, and the play cursor is seen moving through the track
- click [Play] - stops OK
- select Arrangement D1 (or E1)
- click [Play] - runs OK, but play cursor is not seen moving through the track
- click [Play]
==> crash
BR 050 - default track contents
Arrangement C1 has one track with 16 empty events.
All the other arrangements have no events at all.
[this is also in LS 1.4.4]
BR 051 - Crop does not reduce the file size
I loaded an 8 beat loop and cropped off 4/16th at the start and end (giving a 4 beat loop.
When I saved it to disk, with a new name, the file size was the same as the original.
I deleted the loop from the Loops section, loaded it again, clicked [crop], without changing the markers at all, and saved it again. This time the file size was smaller.
BR 052 - Disappearing [x] button in overlapping events
When two events overlap you cannot delete the first one by clicking on its [x] button.
- when you hover over the first (non-overlapping) part of the first event you can see the [x] but when you move over it (i.e. in the overlapping area) it disappears.

Big pic:
http://img440.imageshack.us/img440/6349/lsbr052iz0.png
In the pic, the red x indicate the mouse position.
ohm, sorry
BR 043 - last inserted event moves when you click
After inserting an event, when you select another slice the event moves to be aligned vertically to wherever you click the mouse in the Slicer (or even in the empty space below the track)
BR 044 - Parameter value stops changing
Changing a parameter value stops if you move the mouse too far above or below the track (also occurs in v1.4.4)
BR 045 Overlapping events
When a short event starts and ends within another longer event you do not get the delete [x] icon in the top-right corner for the longer event
BR 046 - Slow response times- heavy CPU usage
- the mouse response stutters and LS is slow to respond when, for example, clicking Parameter buttons or moving parameters
- playback uses 100% CPU
BR 047 - gaps between events
- When you [Lock to loop] to insert a loop into a track each event is slightly wrong
- there is a visible and audible gap between each event. See this:

Big pic:
http://img440.imageshack.us/img440/1787/lsbr047vt8.png
BR 048 - wrong cursors
I get the wrong cursor at various times, e.g the text editing cursor is kept _after_ I have completed editing a loop name, or the double-headed arrow <-->-is kept after I had done some slicing and moved over the function buttons.
BR 049 - crashes when you stop playing an empty Arrangement
- open LS
- click [Play] - runs OK, and the play cursor is seen moving through the track
- click [Play] - stops OK
- select Arrangement D1 (or E1)
- click [Play] - runs OK, but play cursor is not seen moving through the track
- click [Play]
==> crash
BR 050 - default track contents
Arrangement C1 has one track with 16 empty events.
All the other arrangements have no events at all.
[this is also in LS 1.4.4]
BR 051 - Crop does not reduce the file size
I loaded an 8 beat loop and cropped off 4/16th at the start and end (giving a 4 beat loop.
When I saved it to disk, with a new name, the file size was the same as the original.
I deleted the loop from the Loops section, loaded it again, clicked [crop], without changing the markers at all, and saved it again. This time the file size was smaller.
BR 052 - Disappearing [x] button in overlapping events
When two events overlap you cannot delete the first one by clicking on its [x] button.
- when you hover over the first (non-overlapping) part of the first event you can see the [x] but when you move over it (i.e. in the overlapping area) it disappears.

Big pic:
http://img440.imageshack.us/img440/6349/lsbr052iz0.png
In the pic, the red x indicate the mouse position.
ohm, sorry
-
- KVRAF
- Topic Starter
- 1511 posts since 2 Jul, 2004
-
- KVRist
- 52 posts since 31 Jul, 2003 from Valencia, Spain
ohmmmmmm i never received ANY of the betas, and emailed you at least twice about it
the email i used for registration was clarktaylor at wanadoo.es but i now use a gmail address... but neither address has received the betas...
-
- KVRAF
- Topic Starter
- 1511 posts since 2 Jul, 2004
status:
BR 043: Can't reproduce, please retry this in the next beta
BR 044: reverted to the old behavior
BR 045 / 052: I moved the delete button to the upper left corner of the events - now that the events are overlapped visually it makes more sense.
BR 046: very likely related to the same bugs causing the crashes - eliminated some, and found one performance related bug. Another option is that it's related to the Alphatransparency - do you have a very old graphics card or something? - again: please try next beta. The performance on my system is better than ever, so it's a bit strange...
BR 047: fixed, the maximum "hold" was set to 90% by default - changed to 100%
BR 049: fixed
BR 050: this is intentional, but I'll consider changing it.
BR 051: looking into it now.
Thanks again for the accurate bug reports - saves me a lot of time.
BR 043: Can't reproduce, please retry this in the next beta
BR 044: reverted to the old behavior
BR 045 / 052: I moved the delete button to the upper left corner of the events - now that the events are overlapped visually it makes more sense.
BR 046: very likely related to the same bugs causing the crashes - eliminated some, and found one performance related bug. Another option is that it's related to the Alphatransparency - do you have a very old graphics card or something? - again: please try next beta. The performance on my system is better than ever, so it's a bit strange...
BR 047: fixed, the maximum "hold" was set to 90% by default - changed to 100%
BR 049: fixed
BR 050: this is intentional, but I'll consider changing it.
BR 051: looking into it now.
Thanks again for the accurate bug reports - saves me a lot of time.
http://www.livelab.dk - slice up your life
-
- KVRAF
- Topic Starter
- 1511 posts since 2 Jul, 2004
-
- KVRAF
- 10366 posts since 2 Sep, 2003 from Surrey, UK
Well, here's some good news 
[using 1.4.5 beta 4]
BR 052 - fixed
BR 049 - fixed
BR 048 - fixed, not reproduceable in beta 4
BR 047 - fixed
BR 045 - fixed, but can you make the active depth which causes the [x] to be displayed bigger (it's about the top 15% of the track at the moment), the top 25-30% would be good
BR 044 - fixed
BR 043 - fixed
BR 041 - fixed
BR 040 - fixed
BR 031 - fixed
BR 027 - fixed
===================
BR 046 - better, but still slow:
- playing back 2 tracks uses 55% CPU (Athlon 2600+, graphics card is Radeon 9500), when I drag a parameter bar there is a noticeable delay before it starts moving and when I stop dragging, there is a noticeable delay before it stops moving (this is called hysteresis in the UK, I think)
Here's some more results, with these tracks:

Big pic:
http://img442.imageshack.us/img442/8898/lsbr046ud5.png
- when doing nothing, with the mouse over track 2, CPU=3%
- when doing nothing, with the mouse over track 1, event 1, CPU=3-4%
- when doing nothing, with the mouse over track 1, event 2, CPU=27-28%
- when doing nothing, with the mouse over track 1, event 3, CPU=27-28%
- when doing nothing, with the mouse over track 1, event 4, CPU=3-4%
- when dragging tracks 2's event 1's Pan parameter up and down quickly, the CPU rises to 4-5%
- when dragging tracks 2's event 2's Pan parameter up and down quickly, the CPU rises to 94%
- the CPU usage and sluggishness depends on the amount of graphics in the track
- if you hover over an event, doing nothin-else the CPU goes up - the longer the event, the more the CPU
BR 034 - Adjusting [Decay] changes waveform display
- When you change the [Decay] parameter, the waveform changes length significantly, (in the same way that is does if you change the pitch)
- I guess it is just a visual thing but I don't think this should be happening
Here's a screenshot that might help.

Big pic:
http://img442.imageshack.us/img442/5576/lsbr034xt1.png
Gettin' there!
[using 1.4.5 beta 4]
BR 052 - fixed
BR 049 - fixed
BR 048 - fixed, not reproduceable in beta 4
BR 047 - fixed
BR 045 - fixed, but can you make the active depth which causes the [x] to be displayed bigger (it's about the top 15% of the track at the moment), the top 25-30% would be good
BR 044 - fixed
BR 043 - fixed
BR 041 - fixed
BR 040 - fixed
BR 031 - fixed
BR 027 - fixed
===================
BR 046 - better, but still slow:
- playing back 2 tracks uses 55% CPU (Athlon 2600+, graphics card is Radeon 9500), when I drag a parameter bar there is a noticeable delay before it starts moving and when I stop dragging, there is a noticeable delay before it stops moving (this is called hysteresis in the UK, I think)
Here's some more results, with these tracks:

Big pic:
http://img442.imageshack.us/img442/8898/lsbr046ud5.png
- when doing nothing, with the mouse over track 2, CPU=3%
- when doing nothing, with the mouse over track 1, event 1, CPU=3-4%
- when doing nothing, with the mouse over track 1, event 2, CPU=27-28%
- when doing nothing, with the mouse over track 1, event 3, CPU=27-28%
- when doing nothing, with the mouse over track 1, event 4, CPU=3-4%
- when dragging tracks 2's event 1's Pan parameter up and down quickly, the CPU rises to 4-5%
- when dragging tracks 2's event 2's Pan parameter up and down quickly, the CPU rises to 94%
- the CPU usage and sluggishness depends on the amount of graphics in the track
- if you hover over an event, doing nothin-else the CPU goes up - the longer the event, the more the CPU
BR 034 - Adjusting [Decay] changes waveform display
- When you change the [Decay] parameter, the waveform changes length significantly, (in the same way that is does if you change the pitch)
- I guess it is just a visual thing but I don't think this should be happening
Here's a screenshot that might help.

Big pic:
http://img442.imageshack.us/img442/5576/lsbr034xt1.png
Gettin' there!
-
- KVRAF
- Topic Starter
- 1511 posts since 2 Jul, 2004
Nice with some good news. I'll make the ajustments to the "delete event" box, sounds like a good idea.
about BR 034, I'm not completely happy with the way the stretching is visualized, but I still think there should be some kind of visualization of the actual duration of the event if it's stretched. Any ideas? I've been thinking about generating a waveform display that shows more or less exactly what you hear but that's probably overkill. It would be nice if only the loooped part of the event got stretched visually. Stretching bitmaps are heavy operations though, so I have to sort out the performance issues first.
now about the performance issue - does reversing events work for you? if not then I know what's wrong. Also: how does performance compare when the gui is closed (1.44 vs. the new beta?) On my system the two perform almost identical, with the new beta just slightly higher when the gui is shown, and slightly lower when the gui is closed.
strange.... I'll send out beta 4 (build 2) to the list in one hour so you all get the bug free version to test performance. I made a number of optimizations of the mouse-over routines so at least that should be taken care of.
In any case I'll add options to toggle transparency on the settings page.
about BR 034, I'm not completely happy with the way the stretching is visualized, but I still think there should be some kind of visualization of the actual duration of the event if it's stretched. Any ideas? I've been thinking about generating a waveform display that shows more or less exactly what you hear but that's probably overkill. It would be nice if only the loooped part of the event got stretched visually. Stretching bitmaps are heavy operations though, so I have to sort out the performance issues first.
now about the performance issue - does reversing events work for you? if not then I know what's wrong. Also: how does performance compare when the gui is closed (1.44 vs. the new beta?) On my system the two perform almost identical, with the new beta just slightly higher when the gui is shown, and slightly lower when the gui is closed.
strange.... I'll send out beta 4 (build 2) to the list in one hour so you all get the bug free version to test performance. I made a number of optimizations of the mouse-over routines so at least that should be taken care of.
In any case I'll add options to toggle transparency on the settings page.
http://www.livelab.dk - slice up your life
-
- KVRAF
- Topic Starter
- 1511 posts since 2 Jul, 2004
new beta out. further optimizations to the gui and some important bugfixes.
http://www.livelab.dk - slice up your life
- KVRian
- 508 posts since 8 Dec, 2004 from Belgrade
Bug: midi input for liveslice doesen't show in cubase sx 3 midi track output selector. I am not working at home, so I can't check in other hosts. But I will check tommorow...
and now is tommorow: in every other host midi works as expected! (buzz, tracktion, EXT2 demo...)
and now is tommorow: in every other host midi works as expected! (buzz, tracktion, EXT2 demo...)
Last edited by kejkz on Fri Jan 19, 2007 8:48 pm, edited 1 time in total.
-
- KVRist
- 282 posts since 16 Mar, 2005
Can anyone please confirm this here? (I'm not able to do the recording tests, as I use Live as my main sequencer...)
Cheers,
GilJ.
- KVRian
- 508 posts since 8 Dec, 2004 from Belgrade
Confirmed GilJ!
-
- KVRer
- 24 posts since 28 Feb, 2005 from Los Angeles
Latest beta 1.45beta 4.2 crashed Cubase4 when I hit the closer window of LS(closed everything including the program).Seems to run OK in Phrazor.I will look into this more but GUI seems unstable in Cubase4--win x64(amd 4400+).

