BRs done
BR 051 - crop does now reduce file size when saved
BR 033 - recording name in now shown in black when saved
BR 030 - Synchronized recording - now records from the start of the next bar
WooHoo!
FRs done
FR 034 - ability to load loops of 64 (or even 128) beats
FR 024 - Background colour for Slicer and Arrangement thumbnails (done for Slicer)
FR 023 - right-clicking the Beats value now goes up to 64
liveslice 1.45 beta thread
-
- KVRian
- 1298 posts since 11 Jun, 2004 from dublin
DarkStar, you are a superstar! I power user, indeed 
thanks for all of your hard work!
thanks for all of your hard work!-
- KVRAF
- 10366 posts since 2 Sep, 2003 from Surrey, UK
BR updates
BR 048 - wrong cursors - is back
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 047 - gaps between events - is back
- 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.
- the [H] value was 90% again
BR 046 - High CPU load
- when I drag or stop dragging a parameter bar there is a noticeable delay before it starts and stops moving - if there is a lot of graphics in the track
At rest - 2-5% CPU (1-4% in 1.4.4.)
Playback with LS GUI open - 14-25% cyclic (depends on the graphics in the display) (3-6% in 1.4.4.)
Playback with LS GUI closed - 4-6% cyclic (3-7% in 1.4.4)
- when doing nothing, but hovering over an event - 4-7% (0-3% in 1.4.4)
- when dragging the Pan parameter up and down quickly for the only event in the track, the CPU rises to 4-5%,
- I added a different (longer) event and dragging the parameter bar for the first event produced a CPU load of 4-6%, I left LS to type this, then tried again, this item I got 53% !, third time 8%, fourth item 51%, fifth time 6%, six time 52% (3-7% in 1.4.4)
- so the load happens every other time
- is this some weird buffering problem?
- I guess it is related to the semi-transparent events
- can you remind me why this are needed, please?
BR 034 - visual waveform changes as [D] changes
- I am not stretching anything; I was only adjusting the [D] parameter,
- as I understand it, the decay section of the volume envelope applies a fade out to the sample, so before the playback ends the volume starts dropping,
- so the event display should not change in length at all, hence reporting this as a bug
-NB - this section in the Commands Guide is wrong]
New BRs:
[using LS 1.4.5 beta 4.2]
BR 053 - non-working [Play] button- the [Play] button does not work when an arrangement has been selected in Play Slices / Use Arr.
BR 054 - slice location does not show loop in Browser
Using [Locate slice]
- this displays the right loop in the Slicer,
- but does not scroll the Loops section to show which loop it is, you have to scroll up/down to find the loop.
BR 055 - odd colour variations
- when I click an event the background shading for the other events changes
- different events using the same slice are different colours
- when I select an event, the other events change colour too
- the colour changes are different for the same events on different tracks
See the screenshots:
and
Big pics:
http://img291.imageshack.us/img291/6968/lsbr055a4hw.png
http://img291.imageshack.us/img291/7523/lsbr055b6cm.png
New FRs
FR 044 - Keep slice markers until you click crop]
- When you drag the Start or End markers to set the crop positions, keep the slice markers until [crop] is clicked
- otherwise if you drag the Start or End marker too far you can delete a wanted Slice marker and not get it back.
Phew!
BR 048 - wrong cursors - is back
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 047 - gaps between events - is back
- 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.
- the [H] value was 90% again
BR 046 - High CPU load
- when I drag or stop dragging a parameter bar there is a noticeable delay before it starts and stops moving - if there is a lot of graphics in the track
At rest - 2-5% CPU (1-4% in 1.4.4.)
Playback with LS GUI open - 14-25% cyclic (depends on the graphics in the display) (3-6% in 1.4.4.)
Playback with LS GUI closed - 4-6% cyclic (3-7% in 1.4.4)
- when doing nothing, but hovering over an event - 4-7% (0-3% in 1.4.4)
- when dragging the Pan parameter up and down quickly for the only event in the track, the CPU rises to 4-5%,
- I added a different (longer) event and dragging the parameter bar for the first event produced a CPU load of 4-6%, I left LS to type this, then tried again, this item I got 53% !, third time 8%, fourth item 51%, fifth time 6%, six time 52% (3-7% in 1.4.4)
- so the load happens every other time
- is this some weird buffering problem?
- I guess it is related to the semi-transparent events
- can you remind me why this are needed, please?
BR 034 - visual waveform changes as [D] changes
- I am not stretching anything; I was only adjusting the [D] parameter,
- as I understand it, the decay section of the volume envelope applies a fade out to the sample, so before the playback ends the volume starts dropping,
- so the event display should not change in length at all, hence reporting this as a bug
-NB - this section in the Commands Guide is wrong]
New BRs:
[using LS 1.4.5 beta 4.2]
BR 053 - non-working [Play] button- the [Play] button does not work when an arrangement has been selected in Play Slices / Use Arr.
BR 054 - slice location does not show loop in Browser
Using [Locate slice]
- this displays the right loop in the Slicer,
- but does not scroll the Loops section to show which loop it is, you have to scroll up/down to find the loop.
BR 055 - odd colour variations
- when I click an event the background shading for the other events changes
- different events using the same slice are different colours
- when I select an event, the other events change colour too
- the colour changes are different for the same events on different tracks
See the screenshots:
and
Big pics:
http://img291.imageshack.us/img291/6968/lsbr055a4hw.png
http://img291.imageshack.us/img291/7523/lsbr055b6cm.png
New FRs
FR 044 - Keep slice markers until you click crop]
- When you drag the Start or End markers to set the crop positions, keep the slice markers until [crop] is clicked
- otherwise if you drag the Start or End marker too far you can delete a wanted Slice marker and not get it back.
Phew!
-
- KVRAF
- Topic Starter
- 1511 posts since 2 Jul, 2004
thanks Darkstar
more Fixed BR's
BR 048: fixed the text edit cursor. Could not reproduce the double arrow cursor bug.
BR 047: very likely this is because you loaded a file with the max-hold parameter set to 90% - it defaults to 100% now
BR 046: core parts of the gui code has been rewritten, so the speed is no longer affected by the number of events in the track (only if all parameters are changed at once), this also affects the CPU use during playback with the gui open, it now uses very little CPU - better than previous versions, even with alpha enabled. The improvements are most noticable when changing single events in a large track.
I haven't been able to reproduce the "very other time CPU is insane" bug, could be an indicator that something else is wrong. How do you measure cpu? windows task manager?
You ask why we need transparent events, well, it allows you to visually perceive overlapping events. The transparency is not the only addition mind you: events are shown in their real sizes (before, all events were cut off at the beginning of the next event).
In any case I am already writing the code that will allow all this to be user configurable from the settings page.
BR 034: if you change the attack, hold and decay parameters so that the sub exceeds 100% in relative mode you are stretching, that's how I implemented it! If you are not the only one confused by this I'll seriously consider a different approach (like adding a "stretch" parameter or something).
BR 053: this is intentional, not from a usability point of view, but for technical reasons. My playback code can only play the same track once, so the same track cannot be triggered both from the seq. and manually.
You can just copy that arrangement manually. Admittedly, I could copy the arrangement automatically behind the scenes whenever it's updated, would not be too performance heavy, when updating arrangements th gui is (as we all know by now) the bottleneck anyways.
BR 054: thanks will fix, I noticed it doesn't highlight the located event anymore, fixing that too.
BR 055: confirmed and fixed.
FR 044: That won't be as easy as it seems: I'm reusing the slice markers as crop markers...Not that I couldn't change that, and I can see the problem. Note that the undo feature works, up until the point you hit crop (there won't be undo on the crop feature itself, could waste a lot of RAM). So you can recall the deleted slices.
more Fixed BR's
BR 048: fixed the text edit cursor. Could not reproduce the double arrow cursor bug.
BR 047: very likely this is because you loaded a file with the max-hold parameter set to 90% - it defaults to 100% now
BR 046: core parts of the gui code has been rewritten, so the speed is no longer affected by the number of events in the track (only if all parameters are changed at once), this also affects the CPU use during playback with the gui open, it now uses very little CPU - better than previous versions, even with alpha enabled. The improvements are most noticable when changing single events in a large track.
I haven't been able to reproduce the "very other time CPU is insane" bug, could be an indicator that something else is wrong. How do you measure cpu? windows task manager?
You ask why we need transparent events, well, it allows you to visually perceive overlapping events. The transparency is not the only addition mind you: events are shown in their real sizes (before, all events were cut off at the beginning of the next event).
In any case I am already writing the code that will allow all this to be user configurable from the settings page.
BR 034: if you change the attack, hold and decay parameters so that the sub exceeds 100% in relative mode you are stretching, that's how I implemented it! If you are not the only one confused by this I'll seriously consider a different approach (like adding a "stretch" parameter or something).
BR 053: this is intentional, not from a usability point of view, but for technical reasons. My playback code can only play the same track once, so the same track cannot be triggered both from the seq. and manually.
You can just copy that arrangement manually. Admittedly, I could copy the arrangement automatically behind the scenes whenever it's updated, would not be too performance heavy, when updating arrangements th gui is (as we all know by now) the bottleneck anyways.
BR 054: thanks will fix, I noticed it doesn't highlight the located event anymore, fixing that too.
BR 055: confirmed and fixed.
FR 044: That won't be as easy as it seems: I'm reusing the slice markers as crop markers...Not that I couldn't change that, and I can see the problem. Note that the undo feature works, up until the point you hit crop (there won't be undo on the crop feature itself, could waste a lot of RAM). So you can recall the deleted slices.
http://www.livelab.dk - slice up your life
-
- KVRAF
- 2202 posts since 16 Apr, 2004 from between my ears
yes, thank you darkstar.
i've had no time on this round of betas, so i appreciate that you are taking the time to flush out the new version...
i've had no time on this round of betas, so i appreciate that you are taking the time to flush out the new version...
-
- KVRist
- 282 posts since 16 Mar, 2005
Thanks kejkzkejkz wrote:Confirmed GilJ!
Ohm, could you please also send LiveSliceEffect with the next beta, as I'd like to carry on some more tests with new improvements of the recording function of LiveSlice (test the sync function etc.)?
Cheers,
GilJ.
Last edited by GilJ on Sat Jan 20, 2007 1:43 pm, edited 1 time in total.
-
- KVRAF
- Topic Starter
- 1511 posts since 2 Jul, 2004
I will.GilJ wrote:Thanks kejkzkejkz wrote:Confirmed GilJ!
Ohm, could you please also send LiveSliceEffect with the next beta, as I'd like to carry on some more tests with the recording functions of LiveSlice (test the sync function etc.)?
Cheers,
GilJ.
http://www.livelab.dk - slice up your life
-
- KVRAF
- 10366 posts since 2 Sep, 2003 from Surrey, UK
BR 056 - the [A], [H] and [D] parameters
These are all behaving oddly (or rather, I don't understand what is going on. Some of this may be because I do not think that the AHD values should be used to increase the duration of the event (see my post on Stretching).
But anyway, this is what I have found:
Decay:
- as the parameter value is increased the event length increase
- I changed the max value to 300% (by RMBing it), and dragged the bar upwards, but at its highest position the value shown was 100% (the event waveform was 4 times as long)- I think it should be multiplied by the max scale value (to get 300% in this case, or, for example, when the bar is half-way up, the displayed value would be 50% x 300% = 150%)
- I then changed the max to 500% and the parameter bar lengthened but the event waveform didn't
- I then changed the max to 50% and the parameter bar and the event waveform changed to 150% of their original length
Attack:
- as [A] is increased the event length increase
- I could not set the absolute max value to anything other than 100ms (on further test, I could, but the displayed value kept going back to 100)
- I tried later on and the displayed value kept returning to 10!
- similar problem for relative mode
- but the bar and waveform lengths did change when I drag the max scale vlaue up ro down
Hold:
- has only 2 selectable scales - 10% and 300% (and 10ms and 300ms)
- when I click [reset] the [H] values go to 96%
[All three parameters]
- when you change the scale for [A], [H] or [D] by RMBing the scale value at the right-hand end of the track, the parameter bar stays still and the displayed value changes,
- it should happen the other way round - the value should stay the same (or reset to the max scale value) and the bar should move up or down accordingly,
- the events' parameter values should NOT change, until you start dragging the parameter value bars.
FR 045- Ability to specify tempo
I have some loops that are not exactly 4 (or 8 or 16) beats long.
I think I need to be able to override the calculated tempo and specify the actual tempo (especially as the tempo is going to be used for timestretching).
For example, I am looking at a loop in LS, it is named 120_shika, but LS reckons it is 117.13 bpm. In reality, it is slightly over 8 beats long, but LS has assumed 8 beats and under-calculated the bpm.
Also, and perhaps, even more useful, if I could enter the real bpm, LS could calculate the desired length (120 bpm, 8 beats = 4 seconds = 176400 samples) and auto-crop the tail end of the loop for me. Right now I could crop a little off the end of the loop, save it, reload it and see how the calculated tempo had changed, but there is the danger that I will crop off too much.
Also, if the loop was slightly short (so LS would calculate, say 122.47bpm), if I specified 120bpm, LS could add some silence to the tail-end of the loop.
Once the loop is "tempo-matched", I can slice it and save it as a good ACIDized loop.
FR 046 - Going Up a level, in the Browser
- the .. to go up a folder level in the browser are not easy to see, or to click.
- can this be changed to a bigger clearer icon, even just the word [up] in a button?
These are all behaving oddly (or rather, I don't understand what is going on. Some of this may be because I do not think that the AHD values should be used to increase the duration of the event (see my post on Stretching).
But anyway, this is what I have found:
Decay:
- as the parameter value is increased the event length increase
- I changed the max value to 300% (by RMBing it), and dragged the bar upwards, but at its highest position the value shown was 100% (the event waveform was 4 times as long)- I think it should be multiplied by the max scale value (to get 300% in this case, or, for example, when the bar is half-way up, the displayed value would be 50% x 300% = 150%)
- I then changed the max to 500% and the parameter bar lengthened but the event waveform didn't
- I then changed the max to 50% and the parameter bar and the event waveform changed to 150% of their original length
Attack:
- as [A] is increased the event length increase
- I could not set the absolute max value to anything other than 100ms (on further test, I could, but the displayed value kept going back to 100)
- I tried later on and the displayed value kept returning to 10!
- similar problem for relative mode
- but the bar and waveform lengths did change when I drag the max scale vlaue up ro down
Hold:
- has only 2 selectable scales - 10% and 300% (and 10ms and 300ms)
- when I click [reset] the [H] values go to 96%
[All three parameters]
- when you change the scale for [A], [H] or [D] by RMBing the scale value at the right-hand end of the track, the parameter bar stays still and the displayed value changes,
- it should happen the other way round - the value should stay the same (or reset to the max scale value) and the bar should move up or down accordingly,
- the events' parameter values should NOT change, until you start dragging the parameter value bars.
FR 045- Ability to specify tempo
I have some loops that are not exactly 4 (or 8 or 16) beats long.
I think I need to be able to override the calculated tempo and specify the actual tempo (especially as the tempo is going to be used for timestretching).
For example, I am looking at a loop in LS, it is named 120_shika, but LS reckons it is 117.13 bpm. In reality, it is slightly over 8 beats long, but LS has assumed 8 beats and under-calculated the bpm.
Also, and perhaps, even more useful, if I could enter the real bpm, LS could calculate the desired length (120 bpm, 8 beats = 4 seconds = 176400 samples) and auto-crop the tail end of the loop for me. Right now I could crop a little off the end of the loop, save it, reload it and see how the calculated tempo had changed, but there is the danger that I will crop off too much.
Also, if the loop was slightly short (so LS would calculate, say 122.47bpm), if I specified 120bpm, LS could add some silence to the tail-end of the loop.
Once the loop is "tempo-matched", I can slice it and save it as a good ACIDized loop.
FR 046 - Going Up a level, in the Browser
- the .. to go up a folder level in the browser are not easy to see, or to click.
- can this be changed to a bigger clearer icon, even just the word [up] in a button?
-
- KVRian
- 1178 posts since 24 Jan, 2003 from the hilly bit in Lincs, UK
Great work, Darkstar!
Mild-mannered web designer by day - tired web designer by night.
-
- KVRAF
- 2727 posts since 15 Apr, 2004 from Capital City, UK
oh yes, this is going amazingly isn't it! 
one of my osx pals asks me not use it until he can as well! fool..
is this the right place to make feature requests?..
would it be possible to add a function which forces a 'mono' style playback of the event tracks? unless it's already there, in which case i should ask how i enable it?
on another note, if ohm implemented the z-plane soloist algo i could sell my vp9000! (i'm not sure i really would, but that would take LiveSlice into the next dimension.. :drool:
one of my osx pals asks me not use it until he can as well! fool..
is this the right place to make feature requests?..
would it be possible to add a function which forces a 'mono' style playback of the event tracks? unless it's already there, in which case i should ask how i enable it?
on another note, if ohm implemented the z-plane soloist algo i could sell my vp9000!
(i'm not sure i really would, but that would take LiveSlice into the next dimension.. :drool:-
- KVRist
- 178 posts since 15 Mar, 2003 from Windsor, England
Beta 4 build 3 is making my cpu meter spike like mad in cubase 4.01 pc when the GUI is open. Goes back to normal once I close the GUI.
Running at 96k
Dual quadcore intel xeons
geforce 7950
Lynx AES/Aurora 16
eng
Running at 96k
Dual quadcore intel xeons
geforce 7950
Lynx AES/Aurora 16
eng
-
- KVRist
- 282 posts since 16 Mar, 2005
Still isn't working with the latest beta (LiveSlice v1.45 b4_3)GilJ wrote:The latest LiveSliceEffect (which was sent with v1.45b3) doesn't seem to record audio?
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.
Cheers,
GilJ.
-
- KVRAF
- 10366 posts since 2 Sep, 2003 from Surrey, UK
Fixed BRs 
BR 055 - when I click an event the background shading for the other events now does not change
BR 054 - "locate slice" now scrolls the Browser to show the loop name
BR 050 - default track contents -now always no events
BR 048 - wrong cursors - do not occur any more
BR 047 - no gaps between events (the [H] value was being set to 90%)
BR 042 - Increasing number of visible tracks from 2 to 3; the main GUI it is now displayed correctly.
BR 036 - Inserting overlapping event, with Ctrl+LMB, now inserts the event at the desired position, ignoring the Snap setting, and overlapping any existing event.
Updated BRs/FRs
BR 046 - High CPU load - much better:
- playing back 2 tracks uses now uses 11% (it was 55% CPU (Athlon 2600+, graphics card is Radeon 9500), this reduces to 3-5% when the LS GUI is closed,
- there is very little delay when I drag a parameter bar,
- when doing nothing, with the mouse hovering over a track, CPU=3%,
-when dragging a Pan parameter up and down quickly (on a busy track), the CPU rises to 6-7% (was up to 95%)
- not getting the odd "high CPU every other time" that I was getting before,
- but dragging the Slicer scroll bar takes a lot of CPU and the display lags behind the mouse movement (OK in v1.4.4)
- and opening the LS GUI takes longer than v1.4.4
BR 053 - non-working [Play] button
- the [Play] button does not work when an arrangement has been selected in Play Slices / Use Arr.
- "this is intentional, not from a usability point of view, but for technical reasons. My playback code can only play the same track once, so the same track cannot be triggered both from the seq. and manually. "
- Understood, would it be possible for the [Play] button to trigger the track if it is not currently triggered form the host and vice versa?
FR 044 - Keep slice markers until you click [crop]
- I understand the explanation and will use [undo] to get the slice markers back
New BRs
BR 057 - no little [x] icons, sometimes
- sometimes during my testing, the [x] icons, to delete an event, stopped appearing
- I could get them back by closing and re-opening LS
BR 058 - [locate slice] is misbehaving
- the slice located in the slicer does not remain highlighted
- sometimes, [locate slice] would also insert a new event in the track
BR 059 - the parameters values are displaced
- the parameter values are displaced slightly to the left, so part of the leading digit disappears.
It's looking good.
[Thoughts on [Stretch] will follow tomorrow]
[Edit: missed out BR 059 name and number]
BR 055 - when I click an event the background shading for the other events now does not change
BR 054 - "locate slice" now scrolls the Browser to show the loop name
BR 050 - default track contents -now always no events
BR 048 - wrong cursors - do not occur any more
BR 047 - no gaps between events (the [H] value was being set to 90%)
BR 042 - Increasing number of visible tracks from 2 to 3; the main GUI it is now displayed correctly.
BR 036 - Inserting overlapping event, with Ctrl+LMB, now inserts the event at the desired position, ignoring the Snap setting, and overlapping any existing event.
Updated BRs/FRs
BR 046 - High CPU load - much better:
- playing back 2 tracks uses now uses 11% (it was 55% CPU (Athlon 2600+, graphics card is Radeon 9500), this reduces to 3-5% when the LS GUI is closed,
- there is very little delay when I drag a parameter bar,
- when doing nothing, with the mouse hovering over a track, CPU=3%,
-when dragging a Pan parameter up and down quickly (on a busy track), the CPU rises to 6-7% (was up to 95%)
- not getting the odd "high CPU every other time" that I was getting before,
- but dragging the Slicer scroll bar takes a lot of CPU and the display lags behind the mouse movement (OK in v1.4.4)
- and opening the LS GUI takes longer than v1.4.4
BR 053 - non-working [Play] button
- the [Play] button does not work when an arrangement has been selected in Play Slices / Use Arr.
- "this is intentional, not from a usability point of view, but for technical reasons. My playback code can only play the same track once, so the same track cannot be triggered both from the seq. and manually. "
- Understood, would it be possible for the [Play] button to trigger the track if it is not currently triggered form the host and vice versa?
FR 044 - Keep slice markers until you click [crop]
- I understand the explanation and will use [undo] to get the slice markers back
New BRs
BR 057 - no little [x] icons, sometimes
- sometimes during my testing, the [x] icons, to delete an event, stopped appearing
- I could get them back by closing and re-opening LS
BR 058 - [locate slice] is misbehaving
- the slice located in the slicer does not remain highlighted
- sometimes, [locate slice] would also insert a new event in the track
BR 059 - the parameters values are displaced
- the parameter values are displaced slightly to the left, so part of the leading digit disappears.
It's looking good.
[Thoughts on [Stretch] will follow tomorrow]
[Edit: missed out BR 059 name and number]
Last edited by DarkStar on Thu Jan 25, 2007 8:01 am, edited 1 time in total.
-
- KVRAF
- 4143 posts since 7 Sep, 2001 from Melbourne, Australia
I think he is indeed one of the best beta testers I've seen at KvR (in situations where the results of testing are so public).
In my professional life I'm a release manager which means (in this case) I'm also almost 100% responsible for test planning and execution for my company here. This also happens to be a major reason why I don't elect to do a huge amount of beta testing here.
What impresses me most is the methodical AND DESCRIPTIVE way in which the bugs are captured and documented.
I deal with so-called professional testers where the documentation of defects is attrocious - no reproducible scenario, no real description except in nebulous terms - no actual problem identification reference number (so everyone forgets about it the next day). I can't tell you how much potential solution development time can be wasted in defect clarification.
Anyway - my small and relatively off-topic contribution.
Regards
Caleb
In my professional life I'm a release manager which means (in this case) I'm also almost 100% responsible for test planning and execution for my company here. This also happens to be a major reason why I don't elect to do a huge amount of beta testing here.
What impresses me most is the methodical AND DESCRIPTIVE way in which the bugs are captured and documented.
I deal with so-called professional testers where the documentation of defects is attrocious - no reproducible scenario, no real description except in nebulous terms - no actual problem identification reference number (so everyone forgets about it the next day). I can't tell you how much potential solution development time can be wasted in defect clarification.
Anyway - my small and relatively off-topic contribution.
Regards
Caleb
Happiness is the hidden behind the obvious.