Non deterministic pattern sequence

[oddtime]

Hello everybody! I would like to share an idea on a possible feature: an additional way of defining non deterministic pattern sequences. Hope that the following example explains it enough.

Consider having a song with three patterns:

Think for example if you have a 'groove' pattern and many 'drums fill' patterns, then you may want 3 bars of groove followed by a fill, but without determining which one. Together with the already present note probability feature (which is absolutely fantastic!) this would make Hydrogen even more similar to a 'real' drummer.
At the moment the idea doesn't go beyond this scheme.
Since the implementation will require ideas and work for both core and gui, if you like it we could start to discuss on it.

[oddtime]

The sum of probabilities of pattens in a group could be also < 1, that would represent the implicit presence of an empty pattern in the group

[theGreatWhiteShark]

Hey @oddtime,

I think this idea would quite naturally fit into the concepts of the virtual pattern Hydrogen does provided. In there a number of patterns can be combined and only the virtual one has to be selected in the song editor. Allowing for the patterns to have a probably when inside a virtual pattern seems legit.

But what puzzles me is a convenient and intuitive way for adjusting the probability since there is the constraint that all probabilities (including the one of the empty pattern; which I would require to be added explicitly) have to add to 1. Also it would be nice to allow for this feature without introducing a new widget.

By declaring a pattern to be virtual, it could expand vertically and display a list of the included patterns in the left part of the song editor. When toggling for allowing probabilities those could be displayed as horizontal bars next to the patterns and increasing/decreasing the probability of a single pattern would decrease/increase the value for all the others.

[oddtime]

Excellent idea with the virtual patterns.
Your idea makes me think that the virtual patterns could be of two types:

1. type "play only one pattern": like my original idea. probabilities are always automatically normalized so that sum = 1

2. type "play each pattern randomly": each probability is independent, so all patterns can be played together

PS: the type 1. could be also "play only n patterns", with 1 <= n <= tot_patterns_in_virtual_pattern

[oddtime]

When toggling for allowing probabilities those could be displayed as horizontal bars next to the patterns and increasing/decreasing the probability of a single pattern would decrease/increase the value for all the others.

But in this way it is difficult to enter a wanted distribution

I was thinking something like that:

maybe with some more buttons like "probabilities reset" (to 1) and "set uniform distribution" (including or not the empty pattern?...)

In my opinion the distribution normalization should be executed by default after pressing "Ok".

[theGreatWhiteShark]

2. type "play each pattern randomly": each probability is independent, so all patterns can be played together

Allowing for this option can result in no pattern playing at all. If this event is very unlikely to happen due to values set e.g. to 0.99 for all patterns and it first occurs on stage, one would probably consider this a bug. I would only include the possibility of no pattern playing if this was explicitly added by the user.

But in this way it is difficult to enter a wanted distribution

True. But since the an action window make all other parts of Hydrogen unresponsive until it gets closed, it might make the overall UX less fluent.

[oddtime]

True. But since the an action window make all other parts of Hydrogen unresponsive until it gets closed, it might make the overall UX less fluent.

So we should implement both

[oddtime]

Allowing for this option can result in no pattern playing at all. If this event is very unlikely to happen due to values set e.g. to 0.99 for all patterns and it first occurs on stage, one would probably consider this a bug. I would only include the possibility of no pattern playing if this was explicitly added by the user.

Isn't it the case for note probability as well?
However I am fine with your idea (maybe with a toggle button "allow no pattern playing"?)

In case no pattern is selected to be played (and "allow no pattern playing" is off), would you call rand() again for each pattern?

[theGreatWhiteShark]

Isn't it the case for note probability as well?

Sure. But the list of pattern might suggest that at least one of them get's played back.

In case no pattern is selected to be played (and "allow no pattern playing" is off), would you call rand() again for each pattern?

No. I would constrain the normalization function to make the probability of the inserted patterns sum to one.

[oddtime]

No. I would constrain the normalization function to make the probability of the inserted patterns sum to one.

I don't get it...
maybe I did not explain the modes well: I would always constrain normalization in the "play n patterns" mode (see the picture)
Instead "randomly play pattern" mode would be like the current "note probability" but applied on the "patterns" of the virtual patterns, so the patterns probabilities must be independent

[theGreatWhiteShark]

"randomly play pattern" mode would be like the current "note probability" but applied on the "patterns" of the virtual patterns, so the patterns probabilities must be independent

I see. What would be a use case of this? I was thinking about something like having alternative fills/highlights which would require exactly one pattern to be played. I can't think of a scenario right now where it is intend to play back e.g. three patterns at the same time or none all.

[oddtime]

When you want to assign a probability for a group of notes (to be all played, or none)
For example: two crash hits.

[oddtime]

Only a note: in my initial idea the same result was achievable with many contemporary virtual patterns (in "play only one pattern" mode) each containing a different pattern but with non zero empty pattern probability.
The "randomly play patterns" mode condenses all such virtual patterns in only one virtual pattern, that's why I consider it useful.

[oddtime]

Sorry for the c++ question, patterns in virtual patterns are currently stored in a std::set container of Pattern pointers.
Since the probability should be stored as well, what structure would you recommend?

still a set container?

A new "datum" class or a struct with members pointer and probability?
Or a new class for the whole virtual pattern list based on src/core/Basics/PatternList.cpp?

Thanks

[theGreatWhiteShark]

How about something like std::set<std::pair<Pattern*, float>>?

But I'm not a C++ expert. Maybe @mauser or @cme can help.

[cme]

How about something like std::set<std::pair<Pattern*, float>>?

I guess you probably want to be able to look up probabilities by pattern without knowing the probability, so would be better to do something like a std::map< Pattern *, float>. So then you can set probability of a known pattern with virtual_patterns[ pPattern ] = fProbability, look up probability of existing pattern with virtual_patterns[ pPattern ] and iterate over with

for ( auto it : virtual_patterns) {
  Pattern *pPattern = it->first;
  float fProbability = it->second;
 ... }

The existing virtual pattern add function becomes something like virtual_patterns[ pPattern ] = 1.0.

[oddtime]

I think the user may want to customize the order of patterns in any virtual pattern when seeing them in the gui.
Since maps are sorted containers, would that be possible?

I don't know if this is a good way, but right now I am trying with a custom struct

typedef struct {
	Pattern* pointer;
	float probability;
} PatternAndProbabilityStruct;

in a new class PatternAndProbabilityList (copying and modifying the PatternList class) whose private member is

std::vector<PatternAndProbabilityStruct> __patterns;

[cme]

I guess modifications to the array are probably infrequent and they're probably short, so there's no harm in the O(n) time complexity. The main concern really is expressiveness and legibility / maintainability of the code, and that's where the standard containers are really great.

(though by the same token, the std algorithm library is handy for almost all the same things if you have an unordered array!)

[oddtime]

I will think about it better soon.
So are you suggesting to skip an extra PatternAndProbabilityList class?
I could add all the additional methods (for rearranging patterns of virtual patterns) in the existing Pattern class, if that's what you are suggesting.
The struct rather than the std::pair seemed preferable to me since the names are more meaningful, but I don't see other differences.

I guess modifications to the array are probably infrequent and they're probably short, so there's no harm in the O(n) time complexity.

Yes

[cme]

I will think about it better soon.
So are you suggesting to skip an extra PatternAndProbabilityList class?

Certainly if it's just a copy of PatternList. Copying code can usually be eliminated with design tweaks to the class structure.

It might make sense to derive from PatternList and add an additional map of Pattern* -> float to store the probability, and add accessors to set/get the probability, and to pick a random pattern from the list.

class VirtualPatternList : public PatternList {
private:
  std::map< Pattern *, float > m_patternProbability;
public:
  float getPatternProbability( Pattern * );
  void setPatternProbability( Pattern *, float );
  Pattern *pickRandomPattern();
  void normalizeProbabilities();

  bool isNonDeterministicVirtualPattern_ButWithABetterMethodNameThanThis() { return m_pPatternProbability.size() != 0; }
};

If this feels like over-designing, I would just use a std::vector< std::pair< Pattern *, float> > directly in Pattern because it's simple enough, but I think there's some value in having a class for the VirtualPatterns: there's probably some code in Pattern.cpp and Hydrogen.cpp that would more comfortable live there.

I could add all the additional methods (for rearranging patterns of virtual patterns) in the existing Pattern class, if that's what you are suggesting.
The struct rather than the std::pair seemed preferable to me since the names are more meaningful, but I don't see other differences.

Using std::pair etc automatically gives you things like comparison operations so that the things in <algorithms> like sort and find work out of the box. It's also sometimes handy to be able to refer to the type as a self-contained type expression :)

[oddtime]

Thanks a lot

bool isNonDeterministicVirtualPattern_ButWithABetterMethodNameThanThis()

ahah!

[oddtime]

I think there's some value in having a class for the VirtualPatterns: there's probably some code in Pattern.cpp and Hydrogen.cpp that would more comfortable live there.

In that case, considering that __virtual_patterns is currently a private member of class Pattern and it's becoming an object of class VirtualPatternList instead of std::set<Pattern *>, will it be possible to call its methods directly (like setPatternProbability()...) outside of an object of type Pattern? For example in the gui or in Hydrogen.cpp

Just to keep you updated I think that other members and the relative methods (in class Pattern or VirtualPatternList) are required for this feature:

char m_cVirtualPatternMode;		// mode of virtual pattern randomly play
bool m_bAllowNoPatternPlaying;	// used in mode = RANDOMLY_PLAY_PATTERNS
float m_fEmptyPatternProbability;	// used in mode = PLAY_N_PATTERNS
int m_nNPatternsToPlay;		// used in mode = PLAY_N_PATTERNS

Also about the members names, is it preferable to respect "__"+memberDescriptiveString like the ones in Pattern (__virtual_patterns...) for coherence or use "m_"+memberDescriptiveString like m_fEmptyPatternProbability?

[charbeljc]

If this feels like over-designing, I would just use a std::vector< std::pair< Pattern *, float> > directly in Pattern because it's simple enough, but I think there's some value in having a class for the VirtualPatterns: there's probably some code in Pattern.cpp and Hydrogen.cpp that would more comfortable live there.

No, it don't feels over-designing, from python bindings point of view, this is much better than dealing with std containers with raw pointers inside. I'm facing a similar issue with Sample envelopes, which are std::vectors<std::unique_ptr>.
As a consequence of this, the code is crippled with duplicates loops for copying envelopes everywhere. In this case, having a class Envelope would greatly cleanup the code base (see b3160e9 from #1314)

[tboneplayer]

This is an interesting thread I've enjoyed following. This is my first post on any Hydrogen discussions and I first need to admit that I haven't programmed in C++ in twenty-couple years, since I started using Java, so I'm not going to present much code at this point.

Looking at the image above I thought of another way to implement this idea:

Pattern 1 has a one in ten chance of being chosen, Patterns 2 and 4 both have a 2 in 10 chance and Pattern 3 has a 5 in 10 chance. using that total, create an array of 10 pattern pointers and fill it with the actual pointers in the correct ratios:
(p1-p4 are pointers to the four patterns)

pPatternArray = { p1,p2,p2,p4,p4,p3,p3,p3,p3}

Next, use a random shuffling loop to mix them up. Iterate i from 0 to 9 and on each loop, use a random number (from 0 to 9) and swap the array member at i with the spot indicated by the random number. So you could end up with something like

pPatternArray = { p4,p3,p2,p3,p4,p3,p1,p3,p2}

When the non-deterministic random pattern is to be played, use a random number from 0-9 to pick which pattern to play.

Another approach would be to do all the random determination when play is pushed, front filling the piece with the chosen pointers before the sound is started.

This approach is pretty simple and has a pretty small memory footprint.

[oddtime]

Thank you for writing here!
Basically this is what "play n pattern" mode would do, with n = 1, if I don't miss something.
I would rather generate random number between 0 and 1 and subdivide the [0;1] range according to the probability distribution, to make continuous probability values.

Another approach would be to do all the random determination when play is pushed, front filling the piece with the chosen pointers before the sound is started.

I'd like that in real time in case loop is enabled

[sirjohndfox]

Did this feature ever mature?

[oddtime]

Not yet. I was focusing on tuplets first

[cme]

FYI @oddtime: a +1 on the feature idea here -- https://www.facebook.com/groups/linuxmusicians/permalink/5379072725524037/

[oddtime]

Thanks @cme

[oddtime]

@theGreatWhiteShark
are Virtual Patterns working in current master 64355a8?

[oddtime]

Now I got it. But I should think which way would be better for the user. Even if the way I was thinking allows to program the same column-based automation in a song (different virtual pattern for each column), works in pattern mode.

Could the column-base automation handle the random choice of 1 (or n) pattern among the patterns (or a subset of the patterns) in the column (mode that I called "play only n patterns")?

[theGreatWhiteShark]

Could the column-base automation handle the random choice of 1 (or n) pattern among the patterns (or a subset of the patterns) in the column (mode that I called "play only n patterns")?

Sure. This could be set in the Preferences. Either interpreting patterns in one column as separate entities and calculating there presence separately or choosing only one pattern among all with a probability smaller than 1.

[oddtime]

Sure. This could be set in the Preferences.

Yes but it seems to me a property of the song, or better of some patterns in the specific column - because one may want to use two groups of patterns acting even in different modes, in the same column. From the last it follows that the property shouldn't even be of the column, but of a selection of patterns (we can call it virtual pattern) in that column... does it make sense?

[theGreatWhiteShark]

Yes but it seems to me a property of the song, or better of some patterns in the specific column - because one may want to use two groups of patterns acting even in different modes, in the same column. From the last it follows that the property shouldn't even be of the column, but of a selection of patterns (we can call it virtual pattern) in that column... does it make sense?

Sure, it makes sense. But we have to find the right tradeoff between allowing the users to use all possible combinations and settings for the feature and keeping UX as simple as possible. Allowing for more than one pattern to be picked at random increases complexity in both terms of code and UX. It should also provide a significant benefit or we cut it off using Occam's razor ;)

it seems to me a property of the song

As someone who never uses Hydrogen in a live settings I also like a Song-level storing of properties a lot more. But when working live (or with Playlists) things are way more likely this way to fail this way. Having an overall preferences setting for the whole session helps to keep things consistent.

[oddtime]

As someone who never uses Hydrogen in a live settings I also like a Song-level storing of properties a lot more. But when working live (or with Playlists) things are way more likely this way to fail this way. Having an overall preferences setting for the whole session helps to keep things consistent.

mmm... I understand the need to make the UX clear but I still can't think about this overall setting. Maybe this example explains the use I am considering: in one song I want to pick one drums-fill among some at some point in the song. In another song I want to use the undeterministic feature to randomly add a couple of crash hits (they can be in different positions) to the playing pattern that contains the groove.
Also, I wish to be able to do that in two different points in the one song

[theGreatWhiteShark]

The more time I spend fixing the virtual pattern stuff (it's implementation was only a stub), the more I want them to be used and to do useful things.

I like the idea of putting probabilities in the virtual pattern dialog (and make the current virtual pattern an edge-case of the settings) to allow for non-deterministic patterns. How about we try to integrate this in the future 1.3. release? On the way we could also rename "virtual pattern" to something more intelligible, like "container pattern".