Work In Progress: Probability 2.0

[elpescado]

I've been playing with probability attribute for notes and this got me some new ideas how to further improve this feature. I'd like to:

1. Rename "probability" note attribute to "weight" or "importance". The semantics would be same, but it would place less emphasis on randomness.

2. Add two global controls, like "fill" and "randomize" (and invent some more descriptive names). "Fill" would define threshold for note "importance" in order to be played - higher values of "fill" would cause more notes to be played, while lower settings would make patterns more "sparse". "Randomize" would define how that threshold would be randomized. So, instead of note "probability" compared with random value, now note "importance" would be compared with threshold computed from "fill" and "randomize". With "randomize" set to 0, there would be no randomness at all, and every note above threshold will be played. Setting "randomness" to 1 would preserve current behavior - threshold is totally random. Those controls are added to mixer, below humanize controls.

Both "fill" and "randomize" are controllable by MIDI. Users could program a pattern with a few notes with lesser "importance" and while playing song live adjust number of notes ("sparse/fullness") of pattern by twisting a knob on a MIDI controller.

As an extra, this branch allows MIDI control of humanize time, humanize velocity and swing controls, which was not previously possible.

As with previous pull request, this branch should have no impact on legacy behavior - default "importance" value for notes is 1.0 so unless explicitly changed, all notes are played regardless of "fill" and "randomize" values.

Status:
[x] fill and randomize controls
[x] MIDI actions
[x] sampler
[x] MIDI export
[x] rename parameters
[x] graphics
[ ] documentation

[elpescado]

Screenshot:

I'd like to invite you to discussion and have fun testing!

[trebmuh]

Hi @elpescado , I'm having time that I can put on Hydrogen and I'd like to help you with testing this. Unfortunately, it looks like this branch doesn't build against master anymore. Could you please have a look to the conflicting file and rebase against master then I can build and test?

Cheers.

[elpescado]

Hi, I rebased my branch against current master, so it should apply cleanly.

[trebmuh]

Thank @elpescado . I'm adding it to my "Hydrogen todo" list which is now around 25 items (and was a few days ago around 70). Will report back after trying but too late for tonight!

[trebmuh]

Hi @elpescado , I've build from your feature/probability20 branch and here is my first report.

Issue:

Only a small one here, the second knob (the Randomize one) is half visible on the mixer as shown on this screenshot:

Visual improvement suggestion:
(it might be the same that the "[ ] graphics" item on the status on your first message of this thread here)

It'd be great for consistency if visually, the 2 knobs on the master track could be the same than the 3 humanize already on place (velocity, timing and swing), with adding the name on the track, a "0" and a "+" and the lines below each of them.

Here is a mockup of this suggestion:

About the discoverability/usability:

Playing with it a few minutes without reading precisely at the explanations in your first comment (aka: what most users will do anyway), here is my impressions (using only a hit hat line, filled every two hits):

1. when setting the "probability" at around 70%, I can hear that it works, ie: it clearly changes the probability of the notes to be played (which is probability v1 if I remember correctly)

2. when playing with the 2 knob on the mixer's master track (which is probability v2 if I understand correctly), I can hear that:

2a) (the "randomize" knob is at 0%) the "fill" knob is having an impact on how often the notes are played with roughly:

• under ~25%, it doesn't play any hit at all
• between ~25% and ~33%, it randomly play
• over ~33%, it play all the hits

2b) (the "fill" knob is at 0%) the "randomize" knob is having an impact on how often the notes are played in a pretty roughly linear way, ie: ~0 time when ~0% and often enough when ~100% (with still some non-played hit)

After writing it, I'm taking time now to read at your explanation in order to try to understand it better.

OK, I've read at it quickly and I do not understand it better :) I'll leave the night on it and re-read tomorrow !

Hope that helps.

[elpescado]

Thanks for your input!

I don't have this "FX" button... Could it be because I didn't build with LADSPA enabled? On the other hand, I have 4 FX "slots" in mixer.

Anyway, graphics is unfinished. Pushing pixels around is hard job and I don't want to commit to that until I know that general idea makes sense.

And general idea is as follows. Imagine pattern with some probabilities assigned to notes:

This feature divides probability "plane" into three areas. Notes in green area are always played. Notes in red area aren't played at all. Notes in yellow area sometimes are and sometimes dont.

The "fill" knob defines where lies center line of yellow band, and "randomize" knob defines how wide it is. So if you dial "randomize" all way down, there's no yellow area, and notes are either always played or never, and "fill" selects which are which. Turning "randomize" all way up should make everything "yellow area", and "fill" has no effect. Dialing "fill" up moves yellow area down, so more notes go into green area (i.e. plays more notes). Turning "fill" down moves yellow area up, so less notes end up in green area and more in red area (i.e. less notes are played).

I hope this helps!

[elpescado]

Hi,

I have rebased this branch against current master. I have also created a demo song. That song is made of only one pattern. That pattern is looped while I play with probability controls.

• Audio demo (drums only)
• Audio demo (with Arturia Minimoog driven by Hydrogen)

Happy drumming and have fun!

[thijz]

OMG !!!
This is a killer feature for live performance !
I have been thinking about ways to make live performance more 'musical' (see #266 ) but this idea is f*&king AWESOME !!!
Will try it right now !

[thijz]

ok, this seriously rocks !
you can indeed debate about the naming of the controls, but the general idea works
actually seeing the yellow/red/green areas in real time would be great and would make it real easy to understand what is going on

what might be even more intuitive is to have the dots (or bars) in the pattern editor change color (yellow/red/green) in real time of course :-) That way you dont have to look at the probability bars to see what note will be played. This would also give you a complete overview of all notes for all instruments.
I hope this makes sense :-)

[thijz]

some remarks/findings :

• if you modify the velocity of a note, the color of the note (and the color of the 'velocity bar') fades to gray. This is normal behavior for the velocity bar, but this logic is also applied to the 'probability bar' :
  

• when you have 'probability bars' selected and you add a new note to a empty pattern, the probability bars dont apprear right away. If you switch to velocity and then back to probability they do show up

i will test some more now :-)

[trebmuh]

seeing the yellow/red/green areas in real time would be great and would make it real easy to understand what is going on

I'm totally +1 on this. Is it something doable @elpescado ?

[elpescado]

Hi!

I'm back from vacations! Thanks for your feedback. I appreciate it greatly. I like the idea of rendering "probability areas" in note editor. I'll try to implement that, but I'd want to finish this task in original scope first.

[trebmuh]

Welcome back then :)

[elpescado]

Hi,

I have updated this branch, finalized the UI/graphics and tweaked formula for deciding whether notes should be played or not, so that Fill & Randomize knobs have more pronounced effect.

[elpescado]

some remarks/findings :

• if you modify the velocity of a note, the color of the note (and the color of the 'velocity bar') fades to gray. This is normal behavior for the velocity bar, but this logic is also applied to the 'probability bar' :
  
• when you have 'probability bars' selected and you add a new note to a empty pattern, the probability bars dont apprear right away. If you switch to velocity and then back to probability they do show up

I have fixed that two bugs:)

[thijz]

hi @elpescado !

i finally found the time to upgrade to the latest H2 code (from the main repo) and now i really want to start playing around with the probability feature, but ...
I can see that the probability bars are present, but i dont see the probability knob in the main section of the mixer (also cant find any midi action for the probability)

Is this expected? or did something go wrong during the merge of your code in to the main branch ?

Grtz
Thijs

[elpescado]

Hi,

Unfortunately, this feature hasn't been merged yet (the pull request is in "Open" as opposed to "Merged" state). Moreover, I'm afraid it might take some time to be merged, as currently Hydrogen is in 1.0.0 release process, so new features are unlikely to be accepted before 1.0.0 is released:(

[thijz]

Hmmm...
Why is a part of this feature in the main branch (the probability 'bars') ?
This feature is not usable without the main propability control (in the mixer) right? Or am i missing something?

[elpescado]

This might indeed be a bit confusing. "Probability bars" were "Probability 1.0" feature that was merged back in 2016. This pull requests extends that feature.

[elpescado]

I've noticed that this branch diverged from master so that conflicts have appeared. I've resolved them, so now it should merge cleanly.

[thijz]

great stuff !
just locally merged your code into master and i have the controls back :-)

I did notice 1 bug :
When you add a note the probability bar for that note appears > ok
However, when you remove that note the probability bar for that note is not deleted
With the other functions (velocity, pan ...) the bar is deleted when the note is deleted

So when you add a note, change the probability bar then delete that note again the bar stays
Now if you re-add the note again (at the same position) the value (height) of the bar stays the same, but the actual probability value is set to the default starting value
You have to move the bar up/down to get the gui and the actual value back in sync

[thijz]

Hi @elpescado
Shoud i create a bug ticket? Feels a bit weird to keep adding notes to this branch

[mauser]

Hi!

I've started to look into this pull request. I don't want to merge it for the release of 1.0, but this could be merged after the start of the development of the next version. I hope that this will be quite soon, maybe in the next month.

About the feature itself: As you already noted, the term "Fill" seems to be problematic. When first seeing the parameter, i thought of "drum fills" and thought that hydrogen is now able to throw in drum fills :) I believe other virtual drums have this function.. Could it be described as "Density"? I'm really not shure..

In addition, we really would need an entry for the manual for this feature 😄 The idea to the coloring to the note properties view is very appealing!!

[mauser]

Forgot one thing in my last comment.. You could also add OSC support for the new controls (as well as swing). I suppose OSC support wasn't there when you started this pull request. If you don't find the time to implement this, i can assist and do the implementation.

[oddtime]

Thanks for the fantastic feature!
I don't know if it's already included but It would be nice to have automation available for both 'fill' (or 'density' if renamed) and 'randomize'.

[cme]

This is currently on the 1.1 milestone; I'm guessing largely because at the time that meant "not quite 1.0".

@elpescado do you want to get this in for 1.1? If not I'll change the milestone to 1.2 for the sake of having that milestone be meaningful, but it can always be changed back to 1.1 if the fancy takes you :)

[trebmuh]

@elpescado any news here?

[elpescado]

Hi all!

Sorry for late reply, I've been extremely busy recently. I'd really like to see this feature released, but at the same time I don't want to delay any release. I think it's already too late for 1.1 release (I'm not sure, I've been out of the loop for last few months).

As far as I see, there are a few conflicts with master branch. I'll try to update this branch, but it seems to require some work, this branch had diverged with master quite far.

[theGreatWhiteShark]

I think it's already too late for 1.1 release (I'm not sure, I've been out of the loop for last few months).

Jupp. For 1.1 only bug fixes could still be added. But development for 1.2 has already started so it would fit in there.

As far as I see, there are a few conflicts with master branch. I'll try to update this branch, but it seems to require some work, this branch had diverged with master quite far.

Could you target branch development instead? This is were all new stuff is added while the code in master waits to be releases as 1.1.

[theGreatWhiteShark]

Hey @elpescado ,

Development phase for release 1.3 just began. Are you up to tackle this PR in the foreseeable future? But it needs some work and not just a mere rebasing. Lot's of stuff changed internally. Most notably handling of GUI widgets.