Zynseq - A native step sequencer

[riban]

A short (or maybe long, let’s see…) description of the proposed song / pad implementation:

A song is a collection of sequences. Each sequence being a collection of non-overlapping patterns with a MIDI channel and JACK output.
A pad is a way to trigger a sequence, either one-shot or looped.

I propose that the pads are simply an alternative view of a song. Each pad represents a track from the song. The pad triggers the song to start playing (either looped or single-shot) and unmutes that track. It may be possible to configure a pad to unmute at the next loop point. I propose the concept of mutually exclusive groups of tracks. Only one of these tracks may unmuted, i.e. a solo within the group. This allows mutually exclusive pads: press one to play that sequence and press another to mute the first and play the second’s sequence.

The song editor presents all tracks from the song in a grid with tracks running along the vertical axis. Each track has a mute / solo button and tracks may be grouped as described above. A difference here is that there is a global transport which starts and stops all tracks / sequences. The technical implementation is the same (with a few conditional elements).

To configure the pads you would go to the song editor and select the song that represents the pads. (There would be dedicated pad songs separate to normal songs but from same underlying data set.) You then create each pad’s sequence as a track in the song.

I am working on this at the moment. (Boring stuff like encapsulation are sidetracking me - I hope to have something useful soon.) I know it may prove difficult to comprehend from a description so I will get something more tangible to you as soon as I can.

Cheers

[le51]

@riban

The velocity input level is displayed by a green bar in the bottom left corner of the grid

I was asking myself “What is that thing used for ?”
And I was on the way to ask a NFR for assigning velocity to notes.

@riban

I avoided “Launch Pad”

I suggest “launch ZynPad”

Now some feedback,

regarding trigger pad feature:

• its behavior is sometime erratic (eg: midi channel assignment to a given pad affect other pad -but not all other pads-, touch can be unresponsive -its color doesn’t change-, or I touch A4 pad and D1 is highlighted …) It’s hard to reproduce, … well it’s erratic !
• Idea is really cool and while best user experience is with the touch interface, as is, it’s not usable without a touch screen.
• will read more carefully your suggestions about song mode

regarding screen flickering:

• it happens when adjusting the number of steps. I really think user experience would be better if the screen “freeze” while adjusting the number of steps (if the number of steps is shown).
• but also when scrolling down to a lower (or upper) note (I have to admit that I’ve got no idea on how to make it better ) But it’s a hassle when starting a new bassline …

And last but not least, now, some NFR

• default settings (maybe using webconf): number of steps, vertical zoom, center note on the grid …
• ability to save the work

I definitively have to buy you a beer …

[riban]

All good stuff and I hope it won’t surprise you that this is mostly all on the road-map (evidenced by #TODO source code entries ) .

I considered zynpad to be only of use to touchscreens so have give pretty much zero consideration for its use on non-touch screens. I do plan to allow triggering from external MIDI device. This is only a sneak preview of what I am working on so it is very buggy.

Screen flicker is on the road-map and I look at it regularly but am yet to find a solution. I will attempt to include some changes in the next update.

Persistent storage of configuration is defo planned - I just need to figure out where to stick it. Configuration of default values can also be added. I see these as refinements who’s priority will become evident as the bulk of the core feature implementation is complete.

I just realised that I removed auto save when I added extra views. Questions for the community:

• Should we auto save patterns and sequences in which case, when? What should trigger an autosave? When we close Zynthian? When we exit the sequence editor? Should we be prompted?
• Should we provide manual save from the menu?
• Do we want different filenames with different patterns / sequences?

The current file format stores all patterns sequences and songs. There is no limit imposed on the quantity of these but if they grow too large there may be memory issues within the Pi (probably not for some time though). Empty patterns and sequences are not saved and patterns are automatically created, e.g. if you populate pattern 1 and pattern 100 then there will be two patterns saved to file, presented with 98 empty patterns between them.

I like beer but I am doing this to repay @jofemodo and friends for the wonderful work they have done. I am bashfully aware that I do not contribute financially to this project.

[Baggypants]

@le51

I suggest “launch ZynPad”

How about “Zaunch Pyd”

[jofemodo]

@riban

@jofemodo will you look at the library auto build? I can’t remember if you implemented it but it isn’t working for me.

Ups! My fault! I commited a binary compiled for my AMD64 desktop … sorry!

BTW, I think we can safely remove the binaries from the repository and add some lines to .gitignore for avoiding pitfalls like mine in the future. The update system will take care of building the library when needed.

Regards,

[riban]

Sorry @jofemodo but feature/stepseq branch does not build library automatically. If I delete library and reboot the library is not rebuilt.

[Jtunes]

@Baggypants

“Zaunch Pyd”

This forum is sooo wierd… and I love it!

[jofemodo]

@riban

Sorry @jofemodo but feature/stepseq branch does not build library automatically. If I delete library and reboot the library is not rebuilt.

You have to update software for building the library, and the update system have to download some changes. It doesn’t check if binary does exist, if check if there are changes in source code

Simply try this:

cd /zynthian/zynthian-ui/zynseq/build
rm -f libzynseq.so
update_zynthian.sh

Of course, it can be improved, but i don’t think it’s needed. Rest of libraries (zyncoder & jackpeak) are working like that with almost 0 problems in years …

Edit: I just tested and the code is re-built on every update, no need for changes.

Regards,

[riban]

Okay - so do we put the lib binary in the distro and it gets updated with UPDATE? There has to be a lib there in the first place else it won’t work until update is run.

[jofemodo]

@riban

The velocity input level is displayed by a green bar in the bottom left corner of the grid. I wonder if this is sufficient and avoids clinical use of exact velocities . I am not sure where a 3 digit numeric value would best be displayed.

• The green bar sticked to keys is perfectly OK for me. It’s a little bit too small and green doesn’t contrast too much. I will test with other colors …
• Definitely, I would enable acceleration for velocity encoder.

@riban

It is a bit of a mix of menu entries. I have put them all there for now because I need a working interface to develop against but we can consider how to handle this better in the future. I wonder if menu dividers might be beneficial.

Yes. I understand all this. We will find a better way when things get more stable …

@riban

Maybe a BACK button could appear in the topbar when menu is showing. (I think I had that idea but then forgot to implement it.)

I’m OK with that, but ALL touch-specific widgets have to be “optional”. A “touch UI” flag should be added to config ASAP.

@riban

I could use the assert button to assert changes, avoiding grid redraws but there are some things where that reduces user experience, e.g. adjusting the zoom feels like it should do so live rather than after assert.

If it’s working fluid with touch interface, then it can work equally fluid with encoders.
I will take a look to the code …

@riban

I avoided “Launch Pad” due to its similarity with Novation’s product name. I don’t know if that is a registered trade mark.

IMHO, nobody has the right for kidnapping words. “Launch Pad” are a combination of 2 words and we can use it. Of course, if we try to register a product with this name, then Novation will come to open our asses … Anyway, and thinking about it, you are right and we could find a better combination of words … like “trigger grid” … or “Trigrid”

OK OK … i think we have to vote … so, please, tell your proposals and we will make a nice votation

Choosing a name for the ZynStep's "live pattern triggering" feature

Please, make your proposals and we will vote: TriGrid (from Trigger Grid), by Jofemodo Pad Zoo, by @mheidt HARAMSLDGI , as in Highly Advanced Rhythmic And Melodic Sequences Live Deployment Graphic Interface, by @lisacld ZynGrid, by @Jtunes Thanks!

@riban

The touch interface elements I have devised have been based on the principal of minimal use of screen real estate.

But encoder’s interface users don’t want to see these elements. I will add the “touch UI” config flag ASAP.

@riban

Have a think then confirm and I will so as you wish.

I already have thought quite a bit about this question, @riban.

Zynstep should be a MIDI-clock consumer, same that other sequencers already working in the system, or arpeggiators, or a synced delays. In fact, some of the current engines already include stepseqs or arpeggiators, like NoizeMaker, Triceratops or Helm. Also MOD-UI include some MIDI tools that can be synced with MIDI-clock.

Any of these “consumers” shouldn’t make a difference about the “clock source”. ZynMIDIRouter will take care of this, so everything can be synced together flawlessly.

Also, as everything have to work perfectly with an external MIDI-clock, this will be our main use-case. And the best way of avoiding problems with this is to completely erase this difference. I mean, from the application/module POV, there is no external/internal clock. Only one clock does exist. Without adjectives. Only ZynMIDIRouter will know about clock sources …

Thanks a lot!

[lisacld]

I think that the name should be catchy, short, meaningful and easy to remember so I propose HARAMSLDGI, as in Highly Advanced Rhythmic And Melodic Sequences Live Deployment Graphic Interface.

[jofemodo]

@riban

I like beer but I am doing this to repay @jofemodo and friends for the wonderful work they have done.

Ohhh! Thanks a lot, @riban! … anyway, your effort is huge enough to merit for a beer truck …

[jofemodo]

@riban

A song is a collection of sequences. Each sequence being a collection of non-overlapping patterns with a MIDI channel and JACK output.

I would consider using layers for being assigned to patterns. So, when changing the MIDI channel for a layer, the associated patterns got reassigned too.

Of course, every layer has an unique MIDI channel, so finally you have patterns assigned to MIDI-channels too.

Regards,

[lisacld]

Just a humble proposal … I have noticed that while changing Vertical zoom, Tempo, Steps per beat and Steps in pattern, the snapshot encoder is free, so it could be used to change the value in higher increments, say 5 or 10 for Vertical zoom, Tempo and 4 for Steps per beat and Steps in pattern, thus reducing the needed screen refreshes

[riban]

I have pushed some minor changes:

• Improve the visibility of the velocity input level indicator.
• (Hopefully) enable encoder rotation acceleration. (This may reduce the impact of screen redraws.)
• Limit scaling of pianoroll text.
• Step sequencer:
• Fixes hiding selection highlight on some actions.
• Hide parameter editor when switching view.
• Remove libseq binary - should get built with update.

Please test.

[ivanmonterosso]

Wow! Guess what? I was planning to buy an used beatstep Pro … I honestly think you made me save money …

[Jtunes]

Me too! I had my sights on a KeyStep Pro, but I’m glad I waited.

[C0d3man]

@Jtunes

KeyStep Pro

I ordered one. But as I wrote: You never have too many sequencers or arpeggiators.

I have to wait 2-3 weeks… Corona, China…

Regards, Holger

[ivanmonterosso]

Honestly it’s a cute piece of hardware, but 400 Euros are way too much.

[MatFluor]

Two things - one might be “out of scope and not the intention”:

1. For some reason I can select the very first cell to put a note in - bug or user error?

2. What I love about my Microbrute’s sequencer (and a reason to get a Keystep) is that I can simple “step input” the notes I want to have played. As a guy writing a lot of notation and coming more from the “VST” world rather than “Hardware synth”, for me it’s far quicker and more intuitive to “play it in and then have it sequenced”. Is such a functionality something you would consider? MIDI-Keyboard step-input would already be awesome, with e.g. one rotary controlling the step length, similar to now.

Best,
Mat