sjaehn / bschaffl Goto Github PK

After some more playing I found out I couldn't change the velocity, no matter what setting I tried.
Is that already implemented?

In Ardour 8.1 (Arch Linux package) I am experiencing the following symptoms:

1. The timing calculations seem to be very broken; the resulting groove sounds randomly garbled.
2. The errors are highly sensitive to notes being very close to the beat but not exactly; two nearly simultaneous notes at :0000 and :0016 can end up nearly a whole :1:0000 apart.
3. The errors are consistent between replays at the same tempo. Whether they are (proportionally) consistent between different tempos or not seems to depend in a complicated way on the latency compensation settings.
4. Exactly how the timings are garbled also depends on the plugin's latency compensation settings.
5. The errors are rendered when exporting the song, which means that they probably aren't due to insufficient realtime capabilities of the audio/MIDI subsystem.

Attached is a session archive with which you can perform the following steps to reproduce:

1. Play the song, noticing that there is absolutely no groove in spite of the plugin being enabled, groove having been entered into the plugin, and steps process set to 1.0.
2. Try different step process amounts, observing that it has no effect on what you hear.
3. Dial step process back to 1.0 and nudge the MIDI segment on the track named "click" one nudge unit to the right (the unit is configured as :0016 in the session).
4. Replay the song, noticing that now when notes begin ever so slightly after the exact beats, the groove is present but thoroughly garbled.
5. Dial steps process down to 0.
6. Replay the song, noticing that the groove is now garbled differently . Try different steps process amounts.
7. Disable the plugin and replay the song to convince yourself that nudging the notes to go slightly after the beat doesn't cause these symptoms by itself (i.e. not an Ardour bug)
8. Try different latency compensation settings for interesting effects.

Session archive

Soundfont used

It would be very handy to have 2 new sliders:

• one for the overall amp change amount, from 0 to say 4, default 1
• one for the overall time change amount, same range.

When the (time/amp) amount is 0, the (time/amp) data is unchanged, just the latency is applied.
When the amount is 1, the plugin functions as it does now.
When the amount is higher than 1, the changes are scaled by the slider, clipping the velocity at 127.

The main use cases are:

• Automation. You could get the same effect without this feature, but just like with the swing sliders, it can be nice to automate from no change to full effect without having to automate all the sliders.
• For subtle changes: design a pattern with amount turned up a bit and then use it at 1.

In case the only change you made is one or both of the swing sliders, these new sliders are superfluous, they are only needed when there are other changes.

edit: I guess negative amounts could come in useful as well.

Maybe I misunderstood what it is supposed to do.
I thought it would assign a note to a step in order to apply that step's level to it.
It seems to change the timing too.

As you can hear in BSchafflSeries.ardour from #12, every time ardour loops, there are a few notes missing in the first part of each repetition.
When you play the loop for the first time, the notes are not missing.

From my experimentation, it seems the notes are first moved in time and then the plugin looks which step they fall under.
I would expect it to work the other way around, so that I can change the timing of a pattern over the course of a song, but still have the same notes accentuated.
It also makes it easier to predict what the plugin will do to your notes.

If you want to go all out, you could make it configurable, but that's not an important feature, imho.

I build Bschaffl on Fedora 32.
I met the following error message:

Build BOops.lv2 DSP...src/BOops.cpp: In member function 'LV2_State_Status BOops::state_save(LV2_State_Store_Function, LV2_State_Handle, uint32_t, const LV2_Feature* const*)':
src/BOops.cpp:1176:3: error: 'LV2_State_Free_Path' was not declared in this scope; did you mean 'LV2_State_Make_Path'?
 1176 |   LV2_State_Free_Path* freePath = NULL;
      |   ^~~~~~~~~~~~~~~~~~~
      |   LV2_State_Make_Path
src/BOops.cpp:1176:24: error: 'freePath' was not declared in this scope
 1176 |   LV2_State_Free_Path* freePath = NULL;
      |                        ^~~~~~~~
src/BOops.cpp:1181:4: error: 'LV2_STATE__freePath' was not declared in this scope; did you mean 'LV2_STATE__makePath'?
 1181 |    LV2_STATE__freePath, &freePath, false,
      |    ^~~~~~~~~~~~~~~~~~~
      |    LV2_STATE__makePath
src/BOops.cpp: In member function 'LV2_State_Status BOops::state_restore(LV2_State_Retrieve_Function, LV2_State_Handle, uint32_t, const LV2_Feature* const*)':
src/BOops.cpp:1306:2: error: 'LV2_State_Free_Path' was not declared in this scope; did you mean 'LV2_State_Make_Path'?
 1306 |  LV2_State_Free_Path* freePath = nullptr;
      |  ^~~~~~~~~~~~~~~~~~~
      |  LV2_State_Make_Path
src/BOops.cpp:1306:23: error: 'freePath' was not declared in this scope
 1306 |  LV2_State_Free_Path* freePath = nullptr;
      |                       ^~~~~~~~
src/BOops.cpp:1311:3: error: 'LV2_STATE__freePath' was not declared in this scope; did you mean 'LV2_STATE__makePath'?
 1311 |   LV2_STATE__freePath, &freePath, false,
      |   ^~~~~~~~~~~~~~~~~~~
      |   LV2_STATE__makePath
In file included from src/Slot.hpp:26,
                 from src/Slot.cpp:22:
src/Stereo.hpp: In member function 'virtual Stereo FxRingModulator::play(double, double, double)':
src/Stereo.hpp:79:8: warning: 'f' may be used uninitialized in this function [-Wmaybe-uninitialized]
   79 |   left *= rhs;
      |   ~~~~~^~~~~~
In file included from src/Slot.cpp:48:
src/FxRingModulator.hpp:61:9: note: 'f' was declared here
   61 |   float f;
      |         ^

Tricky part (and TODO): Incoming MIDI signals are not 100% synchronous to host time/beat information. Therefore, a MIDI signal (e.g., NOTE_ON) that should start at the beginning of a step may appear at the end of the previous step. And a MIDI signal (e.g., NOTE_OFF) that should end at the end of a step may end at start of the next step.

By now, amplification is for a whole step. If a MIDI signal dropped into an incorrect step (as described above), it will be amplified with an incorrect value.

Addition of some randomness / humanization for velocity and timing has been requested @ linuxmusicians.com: https://linuxmusicians.com/viewtopic.php?f=24&t=21670

There are a couple of UX issues with numeric input controls recently employed to implement #19.

1. The controls don't seem to handle Home, End and arrow key events. In order to position the caret on the desired digit, one must use the mouse. The unhandled key events propagate to the main DAW window (Ardour6 in my case) and move the playhead around.

2. Possibly locale related (I'm using Polish locale): I cannot enter a decimal comma if I accidentally erase it. Neither the period key (letter block or numeric block) nor the comma key works. This makes the comma "precious", and combined with point 1. it makes using mouse for positioning the caret unavoidable.

I'm on Linux/KDE.

Would it be possible to automate the "main" parameters that don't affect latency, like "step process" and the amp parameters?
In Ardour, all parameters show up in the list of automateable parameters, but they don't actually change when you move them.

You can get magnificent effects by using multiple B.Schaffl's in series.
For example one with a little regular shuffle, one with an uneven number of steps for a little polyrythmic dynamic variation and one with a 1 beat length and the middle STR slider dragged a bit left, for a pushed feel, or dragged right for a laid back feel.

It would be very handy if you could do that all in one plugin and save it all as one preset.
I'm imagining tabs like in B.Shapr and inside each tab would be a complete instance of B.Schaffl as it is now.

I've been experimenting with this for a while now, and for me this feature would also fix #10, as you can quickly and easily add true human like variation, in a controlled manner.

The amount controls from #11 would be great to have both per layer and for the whole plugin

Here is a small Ardour 6 session, that hopefully demonstrates the usefulness of multiple instances in series:

BSchafflSeries.zip
.
I don't know if a-Fluidsynth uses absolute or relative paths.
You might have to set the instrument to /path/to/BSchafflSeries/Instruments/industrializer/industrializer.sf2
This instrument has lots of different samples on different velocity layers, so nicely demonstrates the subtle dynamics.

Wow, you got that done incredibly quick!
It looks great, and seems to have all the important functionality.

Except, on my system, it doesn't work yet. :(
When I input a straight 16th note pattern, and leave all the controls at default, I get a sort of shuffle out, with lots of dropped notes.

Attached is an Ardour 6 test session.
Does that work for you?

BSchaffl_test.zip

This would do for level what the current swing slider does for time.

With the slider in the middle, the midi is unchanged.
With the slider all the way to the left, notes falling in the period of the even notes of the pattern have velocity 0 and the notes falling in the period of the uneven notes have unchanged velocity.
With the slider all the way to the right, the even notes are unchanged and the uneven notes are 0.

Its easy enough to do by hand, at most move 8 sliders, but this new slider would be great for automating.

You can probably come up with a better name for this feature. ;)

Of course it would be just as useful for B.Choppr.

The plugin is not big enough to show both the help text and the controls at the same time, and if you'd make it bigger, it would be a bit overwhelming.
Especially if you keep implementing all the extra controls I keep asking for! ;)

The current solution with different categories of controls shown together with the help may be ideal for newcomers, but leads to unneeded clicking, hence a slower creative process.

I propose to have all the controls visible all the time, but have the help text pop in and out of existence, either by floating over the controls with the mouse, as x42-plugins does it, or by clicking on a button, like in the wonderful Uhhyou Plugins.

It would be great if we could link up the controls of various instances of the plugin.
That way you could, for example, tweak the swing amount of a whole song at once.

CHOWTapeModel has this, and calls it "mix groups".
It works as follows: the plugin has a "mix group" drop-down, with the choices "none, 1, 2, 3 and 4".
By default it's one "none" and no controls are linked.
When you set it to "1", the controls are linked to all other plugin instances that have it set to "1" as well.

Thank you for considering!

Please see the screenshot video:

@magnetophon and me discussed about a step shape option to define how to handle note velocities for notes in the middle of a step before. @magnetophon had the initial idea to take the shape feature from B.Choppr. My idea was to use the shape editor from B.Shapr. However, I now think the whole shape editor will be too much. Therefore I now prefer a given set of simple shapes to select (similar to B.Choppr).

However, there is an other problem to think about:

Part of the plugin GUI. White lines shall symbolize the course of amplification.

Fig. a) The present situation is rather simple. The step amp is applied to the whole step in the same way. It doesn't matter if the note is at the start or in the middle of a step. The amplification is constant during a step.

Fig. b and c) What if amplification should follow a (triangular) shape. Should the note in the middle of a step get the full step amp (as in Fig. b) or the note at the start of a step (Fig. c). Or shall we provide both options and let the user decide?

The same can be done with sinusoidal and trapezoid shapes.

Hm, head scratching moment..

=> BSchaffl-1.4.6_1: building [gnu-makefile] for x86_64...
   [host] pkg-config-0.29.2_3: found (https://alpha.de.repo.voidlinux.org/current)
   [target] libX11-devel-1.7.2_3: found (https://alpha.de.repo.voidlinux.org/current)
   [target] cairo-devel-1.16.0_2: found (https://alpha.de.repo.voidlinux.org/current)
   [target] lv2-1.18.2_1: found (https://alpha.de.repo.voidlinux.org/current)
.
.
=> BSchaffl-1.4.6_1: running do_build ...
Build BSchaffl.lv2 DSP...Build BSchaffl.lv2 GUI.../usr/bin/ld: /usr/lib64/gcc/x86_64-unknown-linux-gnu/10.2.1/../../../../lib64/Scrt1.o: in function `_start':
/builddir/glibc-2.32/csu/../sysdeps/x86_64/start.S:104: undefined reference to `main'
collect2: error: ld returned 1 exit status
make: *** [makefile:116: BSchaffl.so] Error 1
make: *** Waiting for unfinished jobs....
/usr/bin/ld: /usr/lib64/gcc/x86_64-unknown-linux-gnu/10.2.1/../../../../lib64/Scrt1.o: in function `_start':
/builddir/glibc-2.32/csu/../sysdeps/x86_64/start.S:104: undefined reference to `main'
collect2: error: ld returned 1 exit status
make: *** [makefile:125: BSchafflGUI.so] Error 1

A simple way to represent many different quantization grooves is to specify relative lengths of the pulses numerically, e.g. [1,2,1,2,2] (for a particular 5/16 groove). The software would then divide each value by their sum, and compute running totals to obtain the onset times of the pulses.

This way of representing grooves can approximate any groove / inflection pattern arbitrarily well, and would have surprisingly good expressive power, esp. when combined with the amount slider (i.e. STEPS PROCESS).

Currently, B.Schaffl updates the latency as you tweak the sliders.
That way it becomes impossible for the DAW to compensate while you tweak.
You have to restart the transport for the timing to be correct, preventing you from effectively tweaking timing related sliders while other tracks are playing.

It would be great if B.Schaffl had a fixed latency, but that would mean either the latency is too high, or the pattern can only be tweaked within a certain range.

A possible compromise would be for the user to set the maximum latency, preferably in bars/beats.
Ideally there would be a snapping effect of the max latency slider, when it is close to the latency needed for the current pattern.

I would like to stress again how much fun this thing is!!! 😄
Have you had a chance to give it a good workout yet, or am I taking up all of your free time with my requests and bugs? ;)

I have a feature request for this great tool: the ability to specify a probability for each step whether the MIDI note is played or not. This would be a very easy way to create constantly changing patterns.

It could be displayed graphically with faders. Either with a second fader per step or with a switch for AMP and probability. Or in another line with a small knob.

What do you think?