LiveSlice 1.47 beta thread

[DarkStar]

Here's a brief test report for this beta [v147 beta 2]:

FRs now implemented:
FR 018 - Refresh after Adding a Track - now displays the new track
FR 019 - Refresh after Ctrl+V an Event - now stays on the destination track
FR 054 - Refresh track selection after Deleting a Track - now track(s) next to the deleted track
FR 055 - Refresh track selection after Re-opening LS - now remembers what tracks were being viewed

FRs not working here
FR 053 - Overlapping slices in RX2 files; see below - the top track is a recording of alternate slices from a RX2 file played back by XT2 and the lower track is a recording of the same RX2 slices played back from LiveSlice
- LS is still truncating the slices.

Big pic:
http://img146.imageshack.us/img146/3913/lsfr053dkl0.png

BRs fixed:
BR 092 - waveforms no longer remain in Slicer when loop is deleted
BR 096 - changing MIDI config details by mousewheel is now kept

BRs not working here:
BR 098 - MIDI Playback channels are set 1 too high (only seen after I close the Setitngs page and re-open it)

New BRs
BR 099 - Access Violations
[v147 beta 2]
Several times during testing today I got Access Violations at 023A4A1D, read of address 00000074.

[-{n8}-]

But you refer to the track / arrangement export right? That won't make it to version 1.47 unfortunately.

Great, thanks for clarifying that. Yes, exporting arrangments or individual wav slices will be great but I'll wait until later.

So far so good on the beta. Haven't had a crash yet.

1-0ne

[DarkStar]

And a couple more:

BR 101 - Different tempo displayed
One of my favourite loops (favourite for testing LiveSlice, anyway ) has a nominal tempo of 120 bpm.

In all previous versions of LiveSlice its tempo was shown as 119.91.
In v147 beta 2, the .rx2 file is shown as 117.32 (the equivalent .wav file is correct at 199.91)

In fact, the tempos for all of the 6 .rx2 files that I checked were shown incorrectly. If it helps they were wrong by different amounts; e.g.
- a 140 bpm loop is shown as 138.52
- a 70 bpm loop is shown as 66.64

BR 100 - [Locate Slice] does not work when the browser panel is expanded
- title says it all

[DarkStar]

If attack+decay >100% then

(2) attack := attack/(attack+decay) and decay:= decay/(attack + decay)

[e.g. If attack = 100% and decay = 30% , I would propose that , internally, liveslice refactors these percentages such that attack = 100/130 and decay = 30/130 (i.e. 77% and 33%) : The ultimate being that if both are set to 100% then internally they both act over 50% of the sample]

Excellent input, thanks.

I really like (2) because it'll allow all three parameters to be at 100% (if the others are zeroed). Still, if you just want as much attack and decay as possible , you just set A and D to 100% and H to 0. 100% could just as well mean "as much as possible" as "the duration of the slice" so that makes perfect sense.

Also, the Absolute mode setting for each parameter is just as important.

And this could get problematic if some of the parameters are in Relative mode and the others in Abolute mode.

But I really would not want the actual values applied to be different from those displayed. ohm, you might remember we talked about this problem some time ago.

On reflection, I think that the [AHD] behaviour should stay as it is - as I recall, the original problem was removing an envelope. And now, resetting the [H] value with middle-click does it. Isn't that OK?

[ohm]

If attack+decay >100% then

(2) attack := attack/(attack+decay) and decay:= decay/(attack + decay)

[e.g. If attack = 100% and decay = 30% , I would propose that , internally, liveslice refactors these percentages such that attack = 100/130 and decay = 30/130 (i.e. 77% and 33%) : The ultimate being that if both are set to 100% then internally they both act over 50% of the sample]

Excellent input, thanks.

I really like (2) because it'll allow all three parameters to be at 100% (if the others are zeroed). Still, if you just want as much attack and decay as possible , you just set A and D to 100% and H to 0. 100% could just as well mean "as much as possible" as "the duration of the slice" so that makes perfect sense.

Also, the Absolute mode setting for each parameter is just as important.

And this could get problematic if some of the parameters are in Relative mode and the others in Abolute mode.

But I really would not want the actual values applied to be different from those displayed. ohm, you might remember we talked about this problem some time ago.

On reflection, I think that the [AHD] behaviour should stay as it is - as I recall, the original problem was removing an envelope. And now, resetting the [H] value with middle-click does it. Isn't that OK?

I do remember the last discussion. But I also discovered that I have been confused by the present behavior myself a couple of times.
There's another solution though:
The problem is this: when you set the D parameter to 60% the H parameter is decreased to 40% without you noticing it. When you then set D back to 10%, the H parameter remains at 40% resulting in a shortening of the event duration.

Now what if the last user defined value of H is saved and restored so that when D is changed from 60% to 20%, H is automatically restored to 80%. Now this will cause confusion when you initially set D to 60%, checked that H was now 40%, and though "hey cool, I did want my H at 40%, nice" then later when you tweak the decay the H is automatically reset...
You would have the opportunity of verifying and manually correcting each parameter, so it's better than loosing the WYSIWYG.

[DarkStar]

I'll go get an espresso and think about that idea

[ohm]

I'll go get an espresso and think about that idea

heh - I had a double macchiato 15 minutes before I wrote that

[DarkStar]

Now what if the last user defined value of H is saved and restored so that when D is changed from 60% to 20%, H is automatically restored to 80%. Now this will cause confusion when you initially set D to 60%, checked that H was now 40%, and though "hey cool, I did want my H at 40%, nice" then later when you tweak the decay the H is automatically reset...
You would have the opportunity of verifying and manually correcting each parameter, so it's better than loosing the WYSIWYG.

So [H] would be set to: min(lastsetH or orignalH, (100 - [A] - [D]))

For example:

Code: Select all

Init/Set H	A	H	 D	Length
	90	5	90	 5	100 %
	90	5	85	10	100 %
	90	5	75	20	100 %
        
	70	5	70	 5	 80 %
	70	5	70	 0	 75 %
	70	5	35	60	100 %
	70	5	55	40	100 %
	70	5	65	30	100 %
	70	5	70	20	 95 %
	70	5	70	10	 85 %
	95	5	95	 0	100 %

- as [D] increases from 5 to 10 to 20, [H] goes down from 90 to 85 to 75
- then you set [H] to 70
- increasing [D] to 60, reduces [H] to 35
- decreasing [D] increase [H]
- so when [D] is 30 [H] is 65
- decreasing [D] to 20, [H] only increases to 70 (its last set value)
- decreasing [D] to 10 does not change [H]

Changing [A] would be handled in the same way as changing [D]

have I got that right?

[audio_dude]

Hi ohm,


I found a bug in the latest beta :

each time I set 0 bar in the arranger, it freezes LiveSlice and FruityLoops (LS 1.47 beta2 and latest version of FL).

Here's what I did :
- open FL (new song: all the patterns are blank)
- just add 1 LiveSlice
- in LS, set bars = 0 in the "arranger" section, and voilà: LS freezes !

Anyone to confirm ?


-----


And I've just found another (minor) bug :

- load a track in the slicer
- change the number of slices to any number
- clear all
- reload the previous track in the slicer (or any other one)
=> in the display box, the number of slices hasn't been reset, and it doesn't actually match the existing number of slices (which seems to be set to 16 by default).

[DarkStar]

Well, I tried the same in eXT v1:

setting Slicer bars to 0 => Arranger track 1 looked odd
Setting Arranger Bars to 0 => locked up my complete PC

So, yes, it is confirmed.

[audio_dude]

Ok ! Thank you, DarkStar !


Moreover, I'm wondering if slicer's tempo is really accurate since, sometimes, it displays things like "1000+ or even 3000+ bpm" (ie: test it with very short samples of 1 second or so, and set 0 bar and X beats in the slicer !)

[ohm]

Thanks for the bugreports.

The arranger 0 bars bug should be an easy fix.

Darkstar: any more of those "access violations" ? More info would be very helpful as I'm not getting them here...

Ok ! Thank you, DarkStar !
Moreover, I'm wondering if slicer's tempo is really accurate since, sometimes, it displays things like "1000+ or even 3000+ bpm" (ie: test it with very short samples of 1 second or so, and set 0 bar and X beats in the slicer !)

This is because some acidized files contain weird negative time signatures! I've fixed my acid-data parser so it corrects these values.

You can work around it by manually setting the time signature values in the slicer.

[audio_dude]

I had "access violations" errors too, in FL (latest version).

I don't know how to reproduce this bug, but, after it occured, I couldn't select files from the file browser anymore because links in the browser seem broken (ie: instead of adding the selected file in the loop list, it displayed a Windows' "open file" window, in order to manually search for the file).

I'll keep searching for reproducing these "access violation" errors.

Keep up the good work, ohm !

[-{n8}-]

I don't know if this was mentioned already, but the most noticible issue for me occured when I was playing back a sequence and expanded the library browse window (which I love btw!)

The plugin screen went all black, with the exception of a few events. Minimizing and reaccessing the plugin window resolved the issue.

I'll try to get a screen shot if it will help.

Also, when I am loading in samples one after another, the names that are displayed are not correct (usually the name previously listed). Usually if I click away from the sample this issue is corrected. Seems to be some kind of delay with the gui updating itself.

I'm using Live 5.2.

1-0ne

[DarkStar]

Darkstar: any more of those "access violations" ? More info would be very helpful as I'm not getting them here...

No Access Violatons today so far.

There's no more info - they occurred when I was doing various things - I cannot see a consistent way to reproduce them.