LiveSlice 1.47 beta thread

[DarkStar]

I think what Architeuthis means is that when you drag the [D] down to 0, the [H] value goes up - this is as designed, as far as I remember.

Dragging [H] up to 100% removes the envelope.

[Architeuthis]

DarkStar, you sure? It seemed like I had to not only put the decay up to 100%, but also turn up the "hold" parameter a bit to remove the envelope.

Well, I found a real problem... maybe... I'm still using v1.46 but LiveSliceEffect.dll doesn't show up in Cubase Studio 4. It does show up in chainer though.

[DarkStar]

This might help with A, H and D:

http://www.asseca.com/darkstar/liveslice-cg/w-4.htm

Scroll down to "The Vol, A, H and D Parameters"

[mabian]

ohm, sorry for the OT; but did you get my PM some week ago?

I got no answer...

Thanks,
Mario

[scuzzphut]

Next beta will be out tomorrow btw.

yay !

[ohm]

1.47 Beta 2 is out

Here's the full list of new features, fixes and changes in 1.47

REX support
Resizable file browser
Enhanced multiprocessor support and thread safety
More midi automation options: slicing and recording can now be controlled by midi (for example: hit a midi-key to record, use mod-wheel to auto slice the recording)
Time signature support, durations in bars + beats in both slicer and arranger.
FR 019 - Refresh after Ctrl+V an Event - now stays on the destination track
FR 018 - Refresh after Adding a Track - now displays the new track
FR 053 - Overlapping slices in RX2 files
FR 054 - Refresh track selection after Deleting a Track
FR 055 - Refresh track selection after Re-opening LS

"Lock to loop" setting is now correctly recalled when opening projects
BR 092 - waveforms no longer remain in Slicer when loop is deleted
BR 096 - changing MIDI config details by mousewheel is not kept
BR 098 - MIDI Playback channels are set 1 too high
fixed "Changing banks, selects another arrangement"

changes:
cleaned up the mouse handling in the sequencer.
Removed the "clear event" feature (there's no need to have empty events in an arrangement)
Middle mouse now deletes events if no parameter is selected, and resets parameters if a parameter is selected
you can reset event parameters by dragging over them with middle mouse button down.

[Architeuthis]

1.47 Beta 2

-Play with the decay setting it to 100% then 0% then 100% and the decay envelope never goes away, even when middle mouse clicking to restore default setting.

-LiveSliceEffect.dll doesn't show up in Cubase Studio 4 (for me at least).

[ohm]

Thanks for your comments.

1.47 Beta 2
-Play with the decay setting it to 100% then 0% then 100% and the decay envelope never goes away, even when middle mouse clicking to restore default setting.

I'll see what I can do to make this more intuitive. The problem is: when you set the decay to 100%, attack and hold is set to 0%, because the relative sum of the envelope cannot exceed 100%.

Check the figure here:

Code: Select all

      /---------\
     /           \
    /             \
   /               \
Attack   Hold    Release
  5%   +  80%  +   15%    = 100%

I could just ignore this and allow an envelope that is 300% of the clip duration. So if you set attack to 100% the hold / decay is ignored. Problem with this is that when you set the release to 20% you'd expect a soft fadeout of the clip, and if the "hold" paramemeter is set to 100%, the envelope never get's to the decaystage.

Here's what I propose: If you set the attack to 10%, hold to 100% and decay to 20%, the hold parameter is recalculated internally without changing the actual value of the parameter, so that what you hear is 10% attack, 70% hold and 20% decay. In other words: if the sum of the AHD parameters exceed 100% the hold parameter is recalculated. If the attack is 100%, the decay parameter is ignored. the envelope will be one long attack.

edit: cleaned up decay/ release confusion. (there's no release parameter)

-LiveSliceEffect.dll doesn't show up in Cubase Studio 4 (for me at least).

Confirmed in the old SX demo I have installed. I'll take a look at it tomorrow.

[scuzzphut]

Possible alternative approach to the attack/decay/hold parameters, ohm.

If attack+decay >100% then

(1) hold = 0 , otherwise hold makes up the difference between attack+decay and 100%.

(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]

[-{n8}-]

Congrats on the new beta ohm. I'm intent on finding some bugs this week.

Is there still any hope for *.wav export? I know we have ACIDized loop import and export but wav format would be a dream

Your hard work is appreciated.

1-0ne

[ohm]

I know we have ACIDized loop import and export but wav format would be a dream

if you only need to export recorded samples from the slicer, the acidized .wav files that are saved, will open in any .wav editor. But you refer to the track / arrangement export right? That won't make it to version 1.47 unfortunately.

[ohm]

Possible alternative approach to the attack/decay/hold parameters, ohm.

If attack+decay >100% then

(1) hold = 0 , otherwise hold makes up the difference between attack+decay and 100%.

(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 don't like (1), because that would make it impossible to make events shorter than 100%.

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.

[scuzzphut]

Possible alternative approach to the attack/decay/hold parameters, ohm.

If attack+decay >100% then

(1) hold = 0 , otherwise hold makes up the difference between attack+decay and 100%.

(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 don't like (1), because that would make it impossible to make events shorter than 100%.

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.

Good point on (1) - Maybe then if attack + decay >100% then hold is ignored, otherwise hold values of 0-100% will be mapped to 0-difference ?

[Architeuthis]

I have a feature request! Built-in stutter capability. It would require a bit of development, but basically the feature would be as such:

-Per-slice parameter setting that allows a held note to cause the slice to loop.
-Per-slice parameter to set loop points
-Per-slice parameter to modulate loop points

This is essentially how Shortcircuit works and is the REAL stutter effect, no buffer required.

[ohm]

I have a feature request! Built-in stutter capability. It would require a bit of development, but basically the feature would be as such:

-Per-slice parameter setting that allows a held note to cause the slice to loop.
-Per-slice parameter to set loop points
-Per-slice parameter to modulate loop points

This is essentially how Shortcircuit works and is the REAL stutter effect, no buffer required.

please start a new topic with FR's I'm not adding more to this beta anyways. I would still like to discuss FR's though, and this particular one sounds interesting. I like the stuttering in Shortcircuit too