Little remark:
It would be an enrichment if MK slicer remembers the docking status and its dock position.
This is a good request! This is already being tested, in the next version there will be implemented.
Quote:
Originally Posted by TonE
Here it is not working then, I do not see any velocity differences.
This is strange. If you see yellow dots on transient lines, then the plugin detects levels. After export, Velocity levels are displayed in the same way. Well, at least should be displayed
I was unsure if the script would take Item FX on an Audio Item into account, meaning:
analyzing transients after the Item FX, but luckily enough, it seems it does.
Dear vanhaze there is also spleeter, if you want to do fun remixes, karaoke, acapella.
+ Improved Slicer accuracy
+ Improved MIDI Trigger accuracy
+ New slider Quantizing Strength
+ New slider Crossfades Length
+ New Slice Quantizing algorithm. Quantizing items to swing grid now able!
+ Addition Ctrl+Wheel for vertical zoom. May be handle for mac users.
+ Zoom by Arrow Keys available. May be handle for notebook users.
+ New internal crossfades algorithm. No more SWS setups.
+ View Gain renamed to Filtered Gain, to avoid misunderstanding.
+ Some minor changes / improvements
+ User Area (set defaults inside the script):
Docked/Windowed Start
Esc to Exit (on/off)
MIDI_Base_Oct - Define Start octave for Export to MIDI Sampler
Default Crossfade Time in ms. (0 = Crossfades Off)
Default Quantize Strength in %. (0 = Quantize Off)
Default MIDI Mode (Sampler or Trigger)
Override Reaper option "Toggle auto-crossfade on split" (on/off)
Override Reaper option "Toggle enable/disable default fadein/fadeout" (on/off)
The snap offset is offset by the X fade length value after quantizating:
See how snap offset are not aligned with transient anymore.
With X fade set to 0, it works as expected.
If I understood the description correctly, this is the correct behavior. The previous version worked the same way. The crossfade is not added before the transient, but to the junction between items, which after the Fill Gap function can be in any place.
I made a quick comparison with the previous version (1.2 below). It can be seen that there is a large indentation, at 1.2, but in some places the same indentation is at 1.3.
One thing:
I have time selection linked to Loop points in Reaper's options.
Whenever i change something in the Slicer window, the time selection is sometimes deleted
Furhermore:
- Would be great if you could delete a marker by double left mouse click (or maybe 1 left mouse
click with a modifier key held down)
I find the "right mouse click > Delete" workflow abit too slow.
One thing:
I have time selection linked to Loop points in Reaper's options.
Whenever i change something in the Slicer window, the time selection is sometimes deleted
The logic of the script is completely tied to the selection of the area. When the script is initialized, it determines the boundaries of the item by the selected area and during the work it constantly checks this data, receiving it and resetting it again. So, MK Slicer cannot work without affecting the selected area, unfortunately.
Quote:
Originally Posted by vanhaze
Furhermore:
- Would be great if you could delete a marker by double left mouse click (or maybe 1 left mouse
click with a modifier key held down)
I find the "right mouse click > Delete" workflow abit too slow.
Just my 2 cents !
This is a good idea!
Quote:
Originally Posted by X-Raym
Hmm I don't think you spot the issue, or maybe I don't understand the answer ^^
Here is with annotations :
See how Snap Offset isn't aligned with transient ?
This would be the desired behavior IMHO, even with Xfade length not 0.
Ahh! Snap Offset! Got it. Fixed
Also, thank you for the bugreports and suggestions!
Also, thank you for the bugreports and suggestions!
Well, you did an impressive job, which can help in lots of situation (like Guitar/Bass in metal music context)
And sharing all these 5000 lines of code for free is very generous to you,
Helping a little is way to thank you for that... and to help make it even better for everyone
Side question : not tested but is it compatible with multichannel file ? How then ? Just using channel 1 or all of them summed ?
Side question : not tested but is it compatible with multichannel file ? How then ? Just using channel 1 or all of them summed ?
Good question!
Multichannel is not implemented. The script can process multi-channel audio, but takes information only from the first channel (or downmix of first two, if it is a stereo channel). Now, a simple and effective way to work with multichannel audio is to create a guide track for analysis with a script, as it is now done for working with multitrack.
Quote:
Originally Posted by Zeno
@cool
Request:
Left Drag in Waveform View = Set Loop (snapping off)
Please
Unfortunately, now it is very difficult to implement. Maybe in the future.
Quote:
Originally Posted by Thonex
Just wanted to say that I'm following this thread closely... amazing work!! Thanks for your fantastic contribution!
Oh ok, bummer. I thought with GetSet_LoopTimeRange & GetCursorPosition something like this could be done quite well.
Thanks for your work anyway
It looks simple, yes. But, unfortunately, the script is already actively uses Loop Time Range. For example, during initialization, the script takes data from the Loop Time Range (this determines the work area) and, during the execution of functions, often restores it and deletes it again. It turns out that any change in the Loop Time Range during the execution of the script can now be lost.
But overall, I like this idea. Perhaps in the future I’ll figure out how to get around this.
An interesting question. Now the trigger is quite accurate from the point of view of the musician, but it is too early to talk about mathematical accuracy. 127 levels are now quite enough, and a higher resolution will be redundant and, most importantly, will not give better reliability. The velocity calculation method does not guarantee such high accuracy.
It looks simple, yes. But, unfortunately, the script is already actively uses Loop Time Range. For example, during initialization, the script takes data from the Loop Time Range (this determines the work area) and, during the execution of functions, often restores it and deletes it again. It turns out that any change in the Loop Time Range during the execution of the script can now be lost.
But overall, I like this idea. Perhaps in the future I’ll figure out how to get around this.
Ah ok, I see. Well, we'll see what happens
One more thing:
It seems that MK Slider is now dockable, but it doesn't remember its position.
If the script is closed and reopened, its in the wrong docker.
An interesting question. Now the trigger is quite accurate from the point of view of the musician, but it is too early to talk about mathematical accuracy. 127 levels are now quite enough, and a higher resolution will be redundant and, most importantly, will not give better reliability. The velocity calculation method does not guarantee such high accuracy.
No, why redundant, vsti which support hi-res velocity could make use of it. But ok, in future maybe, I do not need it, just gave the idea here, as potential improvement dimension. Let us use those 127 levels first.
But Talagan implemented it already here: https://forum.cockos.com/showthread.php?t=172630
One more thing:
It seems that MK Slider is now dockable, but it doesn't remember its position.
If the script is closed and reopened, its in the wrong docker.
I hear you!
1.3.3 and 1.3.4
+ Several additional Defaults in the User Area
+ The script can remember some sliders positions from last session
+ The script can remember dock state from last session
+ Better font scaling
+ Minor script optimizations
At the first start, perhaps, you have to put the window into the dock manually.
+ Several additional Defaults in the User Area
+ The script can remember some sliders positions from last session
+ The script can remember dock state from last session
+ Better font scaling
+ Minor script optimizations
At the first start, perhaps, you have to put the window into the dock manually.
Hi guys, this looks brilliant, and again something I've been wanting for a long time!
EDIT - All installed with the Reapak and found it under Actions > Cool_MK_Slicer
So I import a full track that drifts, from say the 1980s, - then find the first downbeat and then launch the MK Slicer
I am on a 64-bit Mac i5 with 16GB RAM, but everytime I move a slider on MK Slicer it seems to have a spinning beachball and is a little unresponsive? is this normal?
What would be the best settings to beatmap a track to the grid and Reaper Tempo, with the MK settings? so i can start to mess around with it?
Hi guys, this looks brilliant, and again something I've been wanting for a long time!
EDIT - All installed with the Reapak and found it under Actions > Cool_MK_Slicer
So I import a full track that drifts, from say the 1980s, - then find the first downbeat and then launch the MK Slicer
I am on a 64-bit Mac i5 with 16GB RAM, but everytime I move a slider on MK Slicer it seems to have a spinning beachball and is a little unresponsive? is this normal?
What would be the best settings to beatmap a track to the grid and Reaper Tempo, with the MK settings? so i can start to mess around with it?
Apologies and thanks!
Hello! Yes, it is normal. Each time, after the movement of the sliders, the script rearranges the position of the transients (yellow vertical lines) and this process consumes a significant amount of computer resources. It also depends on the length of the processed audio. The longer the audio, the more transients it builds and the more time it takes.
The script does not know how to determine the tempo, so it is better to know the tempo of the audio in advance and set the appropriate tempo of the project.
@cool: do you think it would be doable to implement "quantize by SWS grooves"?
And maybe something completely off: ability to load and save presets?
These things are in the open and I was already thinking about it.
Initially, MK Slicer was developed as a quick tool with simple and affordable functionality. SWS Groove tool, unfortunately, will break this principle. Additional pop-up window with long list will make the work less smooth and I think it’s harder to keep under control from the point of view of the programmer: for example, I will need to somehow monitoring the SWS window and apply the Fill Gaps and Crossfades algorithms only after it is closed. Perhaps everything is easier in practice, but so far I have to postpone.
Presets are one of the popular requests. Here, too, is not so simple. Some settings are adaptive and change depending on the tempo and volume of the material. After the implementation of the presets, I most likely have to somehow turn off adaptability or look for another way to overcome conflicts.
In the latest updates, I found a compromise: now the settings of non-adaptive sliders are remembered after closing the script window. This already greatly simplifies the work within one project or, if you have any settings you like and want to apply them every time you run the script.
Anyway, thank you for your ideas! It is likely that some of this will appear in the future. In one form or another.
No worries cool! The script is already top notch and the mentioned features would only be the cherry on top.
We still can use the SWS groove tool to quantize the items.