Pattern size doesn't fit the timeline

[funkypou]

Hi,

I hope I didn't miss something but it seems that the blocks that represent patterns in the song editor have the same size no matter how many bars long they are. So, if the timeline is supposed to indicate the number of bars, it doesn't work. This can be a problem if we synchronize Hydrogen with other software like Ardour through Jack Transport. It happens that Ardour shows the real bar position in its timeline but not Hydrogen so it's not very convenient when composing and switching from one to the other.

An idea would be to make double squares for a pattern that lasts 2 bars though it would be complicated for patterns that are shorter than a bar.

Another idea is to keep the "1 square = 1 pattern" model but let the user place them properly so that it reflects the real position. For instance, if a pattern lasts 2 bars, the user should let an empty square after it. If he doesn't, no need for Hydrogen to go through a lot of conditions, it could just dumbly play the patterns from their position and overlay them if they are too close to each other. I know that this is some musician stuff and that it could confuse novice users so it could be there as an option.

For the moment, my workaround is only creating patterns 1 bar long but it can lead to make more patterns than needed to have a clear song. Not a big deal, though. My suggestion is more a way to improve this already beautiful piece of software (thank you very much, by the way).

But maybe I'm all wrong and the timeline is just supposed to indicate the number of patterns, not the bars.

[cme]

Hi, the song editor pattern grid cells do indeed represent patterns rather than bars, and their length is defined by the length of the (longest) patterns active in that time slot.

This is a bit of a pain for different length patterns, or for things like polymeters, but does at least allow complete flexibility in changing the lengths of patterns through a composition.

The current development branch (for 1.1 release sometime soon, hopefully) will show shorter patterns that are active at the same time as longer patterns as shorter grid cells. There's also new editing operations in the pattern editor that should make cutting and duplicating patterns.

Any change to the song grid structure would be a long-term development project!

[funkypou]

Hi cme,

Thanks for your answer. I noticed that because I just started using Hydrogen in sync with Ardour as a composition tool. In other uses, one may not care as much about the bar count so it's likely to be a lesser problem. Anyway, for my specific use, I think I can survive using only 1 bar patterns. 😺

[duck57]

The current development branch (for 1.1 release sometime soon, hopefully) will show shorter patterns that are active at the same time as longer patterns as shorter grid cells. There are also new editing operations in the pattern editor that should make cutting and duplicating patterns.

I don't know how the following suggestion would fit into the development you've described here, but what are your thoughts on patterns whose length is an integer multiple of the length of the next-longest simultaneous pattern taking up multiple cells? For example, in a 5/4 song, one instrument has a 10-beat pattern, so each repetition is shown as two connected cells in the song editor grid.

Currently, the ways to handle this situation are either:

1. The long pattern is the cell and the short pattern gets repeated (plus "first half only" and "second half only" variants). I do not use this way.
2. The long pattern is divided into parts and the full pattern looks like a zigzag or stairsteps in the song editor grid. (which is how I handle this situation)

This is less relevant if you're using Hydrogen to describe a player on a drumset, but I am thinking of several percussionists playing overlapping patterns, some of which are two or three times as long as the shortest pattern.

[theGreatWhiteShark]

I don't know how the following suggestion would fit into the development you've described here, but what are your thoughts on patterns whose length is an integer multiple of the length of the next-longest simultaneous pattern taking up multiple cells?

I'm not sure whether there will be anything like a pattern ranging multiple cells one day. After all, the principles 'one pattern - one cell' and 'everything in a column of cells is temporary aligned' are quite fundamental in Hydrogen.

This is less relevant if you're using Hydrogen to describe a player on a drumset, but I am thinking of several percussionists playing overlapping patterns, some of which are two or three times as long as the shortest pattern.

Well, why not opening several instances of Hydrogen with each representing a different percussionist 😉 The transport/playback is chained together using JACK and all the parameters in the mixer can be altered using OSC commands for all instances simultaneously.

[trebmuh]

If that would happen one day, I'd very like to have the choice (in parameters) between:

1. having one square-case by pattern (like it is right now)
2. having patterns length representing as a regular timeline

[theGreatWhiteShark]

I have to admit that I don't understand the problem. Aren't multiple rows of named patterns in combination with a 2D grid more easy to navigate than a 1D time axis? So, instead of "I want to listen to the fill thus I locate to bar 12 where I expect the fill to be" you can just think of "I want to listen to the fill thus I locate to the fill pattern". Or am I missing some use cases?

This can be a problem if we synchronize Hydrogen with other software like Ardour through Jack Transport.

In terms of implementation it's indeed a huge pain (as Hydrogen predates JACK and was not developed with it's synchronization concepts in mind). And there are plans to align the two. But it should work for now (if not, just open an issue and I will take care of it).

[theGreatWhiteShark]

It doesn't seem more complicated than the actual behavior but I guess it's more difficult to modify the code rather than it would have been to do it from scratch.

Indeed. In addition, it wouldn't be compatible with song format currently used.

Furthermore, I found other problems when including Hydrogen in my workflow with Ardour (out of sync recordings maybe due to latency, functions that don't work in Ardour with Jack Transport)

But that's just a constant offset. Having e.g. the first bar a click track in both Hydrogen and the recording software of your choice you can easily match the recordings by dragging them into place.

[funkypou]

Sure, that's a constant offset so it's correctable. But these little issues make me think I might go the wrong way avoiding to get used to Ardour's own MIDI workflow. Both ways aren't perfect so I think I should try to stick with the normal one. I just bought a little MDI keyboard so that should help. Anyway, Hydrogen still rocks for other uses. Thanks for what you do.

[theGreatWhiteShark]

I think I should try to stick with the normal one

Well, in Linux audio the normal way would be to try loads of different programs, select the ones fitting your needs best, and wire these favorites using JACK. It's only a recent development that Ardour is trying to cover everything audio related itself and (probably) became sufficiently stable to be used for proper projects.

[theGreatWhiteShark]

Or how about a display of the beat : bar : tick information next to the playback time at the top left?

[funkypou]

It can help but is not as quick and intuitive as checking the timeline in the context of composing in 2 different software. You'd have to place the playhead to see this information so this can lead to a bit of try and error before you find the spot where you want to put your square on. But it's still a good feature especially if it's much easier to code.

Don't bother about my needs though. I've stopped using Hydrogen along with Ardour because of a few little issues and I think I should learn to master Ardour's MDI workflow. I may have to do it for other instruments anyway.

[oddtime]

Hello guys, I am linking a related issue, especially for the overlapping of different length patterns.
See #974 if you are curious

I am copying a message from there:
I thought to a more valid reason to have multiple sequences: playing all them together.
This would allow to overlap patterns with different length creating polyrhythms (simple example: accents every 3 quarter notes in a 4/4 meter) without writing down all the loop (in previous example: loop period = 3 quarter notes * 4 = 3 bars of 4/4).

It would be useful a new window to see all the pattern sequences each on a separate line like multi tracks in a daw:

[theGreatWhiteShark]

Wouldn't this also been solved by allowing for longer patterns? (4 x patt 1 -> p1, 3x patt 2 -> p2 etc.)

[oddtime]

I am not sure to understand the connection (you mean that in the figure patt 1 is repeated 4 times? It casual...)