Zynseq - A native step sequencer

Its in the menu which selected by a short press on the Layer ( NW) encoder and is down near the bottom., scroll with the Select encoder ( the official way) or use the NW encoder ( the new popular option :slight_smile: ) If you are using a touchscreen Press on the text in the NW position.

image

Unless of course you know that and it’s something else . . .

wyleu’s cinetic art !!!

Midi assignment on pad trigger is erratic imho.
Do you also get how to assign sequence to B, C, D … columns. I just can get patterns in the A column ?

I seem to have a different menu…

Mine is like yours. You have to scroll down to access to midi channel selection.

Ha… I am currently using mouse over VNC… had no idea scrolling down was an option.

image

2 Likes


Stranglers - No more Heroes
Tempo 145
Gm / C / Gm / F
Step Seq: LinuxSampler>SFZ/Pianos/StereoRhodes
Organ: LinuxSampler>SFZ/Organs/B3/b3 organ
Bass: LinuxSampler>SFZ/Bass/DeepBass/bass

3 Likes

The plundering of the 80’s goes on !!!

1 Like

Gives you a rough idea of how the settings on the touch screen is progressing. . . . :roll_eyes:

1 Like

and in memoriam

4 Likes

Updated:

  • Rotate encoder clockwise moves cursor down
  • Buttons in title bar allow press and hold for auto repeat, e.g. changing tempo
  • Tramlines are lighter for white notes
  • A couple of bug fixes

I am still working on the song editor which will facilitate populating the grid with sequences amongst other things.

@wyleu note that the grid does show different colours for unpopulated, loop and one-shot. Currently 64 buttons are populated with patterns 1-64 but you can see the effect by changing the quantity of rows / columns and changing the pad mode.

I haven’t managed to stop the screen flicker. Everyone consider whether @le51’s suggestion has merit, i.e. only assert changes with the assert button rather than live whilst rotating encoder. I think this should only be considered for things that affect the screen refresh. It is advantageous to be able to hear the change in tempo for example.

3 Likes

Good point.

Because of the flickering screen, my opinion is:
If a faster redraw is currently not possible, I would postpone the solution. And since it looks somehow broken, I endorse @ le51’s suggestion.

I found that after I was mucking around. . . :smiley:

I’m testing just now … good vibrations … Just a quick :face_with_monocle: for fun:

It uses:

  • Pianoteq MKII Jazzy => Sequenced
  • LinuxSampler Drums => Finger played on keyboard

I call it “Moebious” :grin:

I will try to add a decent drum line as soon as we have multipattern playing …

Love you, @riban! :smiling_face_with_three_hearts:

6 Likes

Hi @riban!

This version improves a lot the user interaction, but the most important changes are those that users can’t enjoy yet, but paves the way for future versions. And Yesssss! This version is plenty of this kind of changes too!! Congratulations and thanks a lot for the huge effort!! (of course, i perfectly know you are enjoying the coding like a pig in the mud :laughing: )

And now, my revenge (aka, the issue list) :grin: [i will CC to github]

1.)

When enabled with touch, it changes color. When using the switch, color doesn’t change.

2.)

I really love the duration/velocity interaction, but regarding velocity, i would like:

  • having numerical feedback apart from color change. For duration i feel current graphic feedback is enough. (i know this is in the current issue list, but i wanted to add my POW)
  • use encoder acceleration. It takes too much to change values in the 0-127 range …

3.) I don’t like the “back” entry on the menu, but i don’t have a better proposal yet … :yum: In fact, mixing in the same menu parameters like “steps per beat” and a link to “Song Editor” … OK, i know you can feel it too … :grin:

4.) Pad Trigger => I think “Launch Pad” is a better name, and much more “popular”.

5.) Refreshing grid seems to be slow. I don’t know if speed can be improved, but if it’s not easy, you could think of refreshing only when parameter is asserted.

6.)

I suppose you mean the 4 arrow-buttons. It seems to be only useful for touch-screen users, being confuse and distracting for the rest. I would like to have the option of enabling/disabling this kind of touch-only widgets, so UI experience can be optimized. Encoder interface users normally have smaller displays, so screen space is precious, etc.
7.)

This is the main stopper for merging with master. As soon as the stepseq be a pure clock-consumer, i will start merging with master.

Regarding development & debugging itself, please, please, remove the:

Unhandled MIDI message XXX

message from the log. It makes very difficult to debug using the log.

Thanks a lot!! Really!

I already did it, @riban. Please, pull it to your local copy.

Regards,

Getting errors on two different machines of two tried on update. . . .

– Logs begin at Mon 2020-05-11 15:57:47 BST. –
May 11 16:09:04 zynthian-ceed startx[428]: File “/home/pi/zynthian-ui/zyngui/zynthian_gui_stepsequencer.py”, line 70, in init
May 11 16:09:04 zynthian-ceed startx[428]: self.libseq = ctypes.CDLL(dirname(realpath(file))+"/…/zynseq/build/libzynseq.so")
May 11 16:09:04 zynthian-ceed startx[428]: File “/usr/lib/python3.7/ctypes/init.py”, line 356, in init
May 11 16:09:04 zynthian-ceed startx[428]: self._handle = _dlopen(self._name, mode)
May 11 16:09:04 zynthian-ceed startx[428]: OSError: /home/pi/zynthian-ui/zyngui/…/zynseq/build/libzynseq.so: wrong ELF class: ELFCLASS64
May 11 16:09:06 zynthian-ceed startx[428]: PNG file: /zynthian/config/img/fb_zynthian_error_ip.png - Application must supply a known background gamma
May 11 16:09:06 zynthian-ceed startx[428]: /zynthian/config/img/fb_zynthian_error_ip.png is 1366x768 PNG image, color type RGB_ALPHA, 8 bit, file gamma 0.4546
May 11 16:09:07 zynthian-ceed startx[428]: Zooming image by 100%…done

I just uploaded a fixed version of the library. The version that @jofemodo uploaded was using a different CPU command set and the auto-build of libseq isn’t working. (I tried reboot.) The current version should fix @wyleu’s issue and @jofemodo’s loop button colour issue. (I actually fixed that this morning but had to go to work before uploading.)

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

That’s fixed it … :smiley:

Thanks for the feedback. Here are some comments…

  1. Fixed.
  2. 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 :wink:. I am not sure where a 3 digit numeric value would best be displayed.
  3. 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. 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.)
  4. Grid refresh is bugging me. I am trying many different things (which is why progress may appear to have slowed). It is only slow on a RPi4 when the encoder is used. I have tasked my daughter with building a Zynthian using a RPi3 so should be able to test against that platform soon :wink:. 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.
  5. I avoided “Launch Pad” due to its similarity with Novation’s product name. I don’t know if that is a registered trade mark. (I don’t see indication of such on their website.) Also, it isn’t really launching anything, hence the use of trigger. It is really just another view of the song (I will explain later) so words like; player, trigger, pad may be useful. Think on it and we can decide before we release this proper.
  6. The editor has the four buttons for touchscreens and the title / value display. It all fits within the available space of the topbar but we could add a configuration to enable touch interface elements. I don’t think screen size is the driving factor. Some people use fairly small screens with stylus whilst others have massive screens with no touch interface. The touch interface elements I have devised have been based on the principal of minimal use of screen real estate.
  7. I have been putting this off until I have time to deal with an awkward element. To be purely driven from MIDI clock I need to add a phase locked loop to ensure MIDI messages are sent at the correct JACK sample position. This particularly becomes relevant when CC messages and interpolation are implemented. I know we want to be able to drive from external MIDI clock (like it was in PoC) so I do need to do it but it will take some time and there are some large bits of functionality needed to make it properly operational which are occupying my time at the moment. I am also aware that, although the *nix way is to have lots of individual modules strung together, there is an overhead to each JACK client and we could use libseq as a replacement for jack-midi-clock reducing that overhead. It can have the same features with individual output for clock separate to notes / CC. It reduces the maintenance by not requiring extra modules installed and associated service management. Tempo, transport, etc can all be controlled from any zynthian module. We would probably want to move initialisation of the library out of the sequencer though. Have a think then confirm and I will so as you wish.

I left the debug message in and was not seeing unhandled MIDI messages but yes - it shouldn’t be there so thanks for removing. Everyone remember - this is still alpha :stuck_out_tongue: