Jump to content

MIDIbox SEQ V4 Release + Feedback


TK.
 Share

Recommended Posts

Oh my ... that step recording is awesome. It works perfect for getting chords (completely) on the right spot.

How could we've missed that all the way!

 

Great idea and well implemented TK !

Lots and lots of fun!

 

I think I finally have to do a new "Live recoding with MBSeq" video. :rolleyes:

Edited by stuartm
Link to comment
Share on other sites

Yes, a new video will be necessary, because this (actually obvious) feature changes the way how to enter&edit sequences entirely, at least for those users who are working with an external keyboard. The usage is now very similar to MBSEQ V4L :smile:

 

Alright, here a new version: http://www.ucapps.de/mios32/midibox_seq_v4_086_pre3.zip

 

still work & progress, but I considered some of your proposals and I'm interested on more ideas to improve the recording mode.

 

Changes:

  • improved CC recording
  • ALL button considered now
  • press&hold EDIT button to select the view mode, select random or euclid editor, etc (that what was previously done with the SELECT button)
  • the SELECT button gives you now an alternative possibility to enable recording, e.g. for the case that you want to enter a chord with two hands on your MIDI keyboard.
    Note that by pressing & depressing a GP button recording mode will be deactivated again.
    Just use the datawheel to select the step into which you want to record something
  • avoid MIDI note hangs if recording function is used for a chord layer
  • CLEAR button now clears all selected tracks

 

Comments to your other proposals:

 

Does the ALL button work with this step recording thing?

 

haven't considered this yesterday evening, should work now

 

 

Maybe Layer View should be automatically activated while the step is held for recording

 

conflicts with the ALL button behaviour where you want to get an oversight about the steps into which the MIDI events are recorded.

 

 

Here's an idea to extend this: (external midi remote control ideas)

 

It's a different topic, which needs more alignment with different users to find out how they would use it.

E.g. I wouldn't like to enforce the usage of a certain MIDI device like a Korg Nanocontrol, it would be better if such a remote control option would also consider other devices.

I added your proposals to the Wishlist and will come back to this in a separate forum topic sooner or later once the current MIDI learn topic is finished.

 

 

Currently, to select an edit view you have to activate edit by pressing the edit button, then press select to show the view menu, then select a view with the GP buttons.  It might be more intuitive to show the view menu whenever the edit button is pressed and held - so, to select a view: press+hold edit button, then select a view with the GP buttons, then release the edit button.  This would also leave the SELECT button available in edit mode for some other function you might want to add later.

 

I totally agree with this, and therefore changed the selection.

(originally I wanted to use the SELECT button to enable the record function - it's implemented this way now)

 

 

I cannot comment on other changes, because new features keep cropping up faster than I can learn old ones... so the following might already have a solution, which I didn't find with searching "clear" in the menu pages section of the manual, but I noticed that even when you have several tracks of one group selected, pressing CLEAR will clear only the active track (the one that's on the screen). To me it would have made sense that it had cleared all selected tracks. But maybe there's a reason for this, or there's something I've missed..?

 

The reason was, that only a single track can be stored into the UNDO buffer.

However, I guess that most people don't use the UNDO function anyhow, or would accept this limitation. Therefore I enable multi-track clear

 

Best Regards, Thorsten.

Link to comment
Share on other sites

It's a different topic, which needs more alignment with different users to find out how they would use it.

E.g. I wouldn't like to enforce the usage of a certain MIDI device like a Korg Nanocontrol, it would be better if such a remote control option would also consider other devices.

I added your proposals to the Wishlist and will come back to this in a separate forum topic sooner or later once the current MIDI learn topic is finished.

 

I didn't mean to suggest the nanokontrol as anything other than an example of a controller that would work well, and which would respond to simple LED feedback signals from the SEQ.  The seq would just be providing "edit currently selected step's parameter layer X"  CC's - that would work with any controller.  Anyway, you're right - it's a different topic.  Seeing how easy it was to set CC values in the new step record mode just gave me the idea.

 

...and actually, that just gave me another idea: if the Seq provided external control CCs for each of the buttons and encoders available on the hardware frontpanel (and maybe the BLM buttons too), users could just build a core, wire up two LCDs, and use whatever midi controllers they have around as a control surface - I can think of a few controllers or combinations of controllers that would work well.  That could make building a functioning seq v4, or extending the functionality of Seqs with the wilba frontpanel very easy and inexpensive.  But that's a totally different idea and doesn't belong here right now, just figured I'd mention it so I don't forget it.

 

The step recording thing is really useful.  I'm having a lot of fun with it.  Thanks again.

Edited by borfo
Link to comment
Share on other sites

...and actually, that just gave me another idea: if the Seq provided external control CCs for each of the buttons and encoders available on the hardware frontpanel (and maybe the BLM buttons too), users could just build a core, wire up two LCDs, and use whatever midi controllers they have around as a control surface - I can think of a few controllers or combinations of controllers that would work well.  That could make building a functioning seq v4, or extending the functionality of Seqs with the wilba frontpanel very easy and inexpensive.  But that's a totally different idea and doesn't belong here right now, just figured I'd mention it so I don't forget it.

 

Such a function is already available, but not documented: a master/slave remote control! :smile:

 

In Remote Master mode it sends LCD and LED updates to a MIDI port, and receives MIDI events for button and encoder movements.

The same in Remote Slave mode, just vice versa.

 

The protocol is based on SysEx.

 

I implemented this in order to allow a fully stuffed MBSEQ V4 to connect and remote-control another "core-only" device without control surface.

It would also be possible to connect to a computer app which provides the protocol.

Later (iPad came to the market) also the usage of a table PC came into my mind.

(While I'm writing this: I remember that somebody started with a Lemur based app, but can't find the posting!)

 

Idea was, that a newbie could explore the possibilities of MBSEQ by only building the core before he builds the control surface.

Another idea was, that somebody could implement an app which acts as some kind of "frontpanel design", so that somebody can design his own "personalized control surface".

 

However, these were only wild ideas, at the end I came to the conclusion that the benefit/effort ratio is not so high, resp. that I would need help from somebody who takes over the implementation of the app part. And maybe another guy who writes the documentation (because this is a lot of effort as well...)

 

 

and maybe the BLM buttons too

 

The BLM protocol is already based on MIDI.

Actually the BLM16x16+X is a remote device - and even a virtualized version is available, see: http://www.ucapps.de/midibox_seq_manual_blm.html

 

 

The step recording thing is really useful.  I'm having a lot of fun with it.  Thanks again.

 

I need some feedback on the current implementation:

 

Currently the step recording can be temporary enabled by pressing a GP button, and it can be permanently enabled by the SELECT button.

Problem: if somebody turns on recording via SELECT button, the mode will be disabled once he presses a GP button (e.g. to select, activate, deactivate a step).

 

Therefore I think it's better to remove the initial "activation via GP button" function.

 

And thinking a step further: recording could also be enabled by pressing EDIT + a GP button (e.g. GP6 and GP7 are unusued yet)

This would free up SELECT for other things.

 

Opinions?

 

Best Regards, Thorsten.

Link to comment
Share on other sites

Such a function is already available, but not documented: a master/slave remote control! :smile:

 

In Remote Master mode it sends LCD and LED updates to a MIDI port, and receives MIDI events for button and encoder movements.

The same in Remote Slave mode, just vice versa.

 

The protocol is based on SysEx.

 

Cool...  Where is that in the codebase?  I wouldn't mind taking a look.

 

The problem with sysex control is that most cheap commercially available controllers can't send be set up to send sysex messages.  Again, the nanokontrol as an example: it can easily be set up to send CCs or noteon/noteoffs, not sysexes.  So, in order to use a midibox remote control protocol based on sysex, you'd have to put a translator program in the middle somewhere, to convert sysexes to CCs and back again.

 

But if the SEQ provided CCs and noteons/offs mapped directly to the frontpanel button functionality (maybe on a dedicated in/out MIDI port/channel so they wouldn't interfere with the existing CC implementation), users could easily configure commonly available controllers to send/receive those midi signals, and there would be no need for a sysex translator in the middle.  And LED feedback would "just work" on many controllers if the SEQ sent LED feedback messages out on those CCs.

 

Granted, there are only so many CCs and MIDI Notes available, but if you used a dedicated port/channel for remote control, there would be 256 controls available...  That's more than enough to map all the frontpanel controls.

 

With direct mappings to CCs and noteon/offs, the implementation on the user side would be trivial - the only documentation required would be a list of the CC/note assignments.

 

 

The BLM protocol is already based on MIDI.

Actually the BLM16x16+X is a remote device - and even a virtualized version is available, see: http://www.ucapps.de/midibox_seq_manual_blm.html

 

I've looked at the BLM implementation, code and docs - I have a few ideas for BLM implementations that I may develop at some point.  There's some complex stuff going on in the protocol that requires some processing on the controller side. (eg: signals from the SEQ light rows of leds, etc. - it's not a one-to-one button-cc mapping) - it's a little hard to figure out completely from the available docs and code, but I have a pretty good idea of how it works.

 

I'm thinking that if you could have a straightforward one-to-one BLM button to CC/note mapping, then it would also be trivial to implement a BLM using, for example, novation launchpads.  All the user would have to do is configure the device's buttons to match the desired SEQ CC's (or edit a config file on the SEQ for MIDI controllers that have fixed CC/note assignments), and the BLM with LED feedback would "just work".

 

Currently, you'd have to write a translator program to sit between the SEQ and the external midi controller

 

There are 256+x buttons on a 16x16 blm - this could be handled on a few midi channels on a dedicated control midi port.  Although it may be a lot of midi traffic and might not be practically possible for technical reasons.

 

 

 

Opinions?

 

I've got to go out for a bit and I haven't had a chance to check out the newest firmware much.  At first glance I think it's less intuitive with the select button than with the GP+hold, and I'm not sure how the ALL functionality works yet.  But I'll dig into it tonight and provide some comments once I've had a chance to really check it out.

Edited by borfo
Link to comment
Share on other sites

I would prefer to keep the GP-hold method, it's very much like parameter locks on the Elektron machines, very intuitive. Edit+a GP for permanent step rec could work as well.

 

Thanks for the feedback! I find it better as well, on the other hand I don't like the flaw in combination with the SELECT button.

However, if nobody really minds about this issue, then it's ok for me ;)

 

Remote Control: the code is located in seq_sysex.c: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fcore%2Fseq_midi_sysex.c

keyword "remote"

 

Since the hooks are there, it wouldn't be so difficult to provide a similar solution for Note/CC based communication.

Update: I just noticed that Button and Encoder events are already sent as Notes and CCs - just only the LED state is SysEx (for best performance).

 

 

I'm thinking that if you could have a straightforward one-to-one BLM button to CC/note mapping, then it would also be trivial to implement a BLM using, for example, novation launchpads.

 

A one-to-one LED control is too slow over a common MIDI line. It could work over a USB MIDI based line assumed that a novation launchpad can handle USB as fast as MIOS32.

 

Best Regards, Thorsten.

Link to comment
Share on other sites

Two launchpad minis arranged like this would make a great little BLM...  Four of them would be a great 16x16, with 4x16 extra buttons.  The button LEDs are bicolour and can be lit in 16 different colours/brightnesses.  There are several other inexpensive commercial button grid controllers that would also work if it is technically feasible to send/receive messages fast enough.

1TAhIoil.jpg

 

How many messages per second would it have to be able to handle?  The old version of the launchpad only handles 400 messages per second, but the newer Launchpad S and mini are much faster - apparently something on the order of 40x faster.  There's also a "rapid led update" mode that cuts the number of messages required to update the entire led grid in half, and a buffering feature, but those would be specific to the launchpad and wouldn't work on other controllers.

 

Here's the programmer's reference - has all the details of the MIDI implementation - how to light the leds in different colours, etc:

http://d19ulaff0trnck.cloudfront.net/sites/default/files/novation/downloads/4700/launchpad-s-prm.pdf

 

I just sent you some cash - buy a launchpad mini with it if you're interested in experimenting with it.  Or just buy yourself a lot of beers.  The SEQ and the whole array of devices you've invented and keep improving are incredible, and because you're so committed to open source/hardware they are an amazing gift to all the people who build and use them.  I've been thinking I should send you something anyway as a thank you, so no pressure to spend it on a launchpad.  Do whatever you want with it.

Edited by borfo
Link to comment
Share on other sites

Thanks a lot for the cash!  :phone:

Of course, once I have it on my hands, I will get a strong wish for a perfect integration into my setup ;)

 

But please note, that it can take some time - one step after another!

/edit: removed private stuff..

 

Best Regards, Thorsten.

Link to comment
Share on other sites

No worries - like I said, I was thinking I should send you something anyway, so really don't feel like you have to buy a launchpad with it.  Obviously it'd be great for me if you did, since that would probably result in you eventually programming something awesome into the SEQ that I could also use.  But you really have given the world a great gift with all the midibox stuff already.  No pressure at all to buy a launchpad.

 

 

edit:  haha - just saw your last post.  That's great news.  I look forward to seeing what you do with them.

 

I thought the extra column of round buttons on the right side when two controllers are used could be used to page up and down on the vertical axis to access 8x8 notes in grid view...  If the LEDs in that column lit to indicate which "pages" had notes in them, that would make it pretty usable as a BLM even with only 8 rows of notes.

 

Anyway, no pressure, and certainly no hurry.

Edited by borfo
Link to comment
Share on other sites

Well, I'm not blind...

I developed the BLM16x16+X at a time where nothing comparable was available on the market aside from the super-expensive Monome (which only supported mono-colour LEDs). Multiple people tried to help me to make this project more DIY friendly (e.g. by creating PCBs), but without much success. We had problems to find an inexpensive Button/LED combo which will be available over long-term, and to make the PCB(s) "shipping friendly" for a small community.

 

Meanwhile it doesn't make much sense to continue with this approach anymore: although a BLM16x16+X has still more button/LEDs with a perfectly suitable layout, the Launchpad Minis are cheaper, have a higher quality, could be used together with other SW and even have RGB LEDs instead of Duo-Colour LEDs -> more bang for the money.

 

So, if such devices become some kind of inexpensive standard, it really makes sense to support this - not only for MIDIbox SEQ, but maybe also for MIDIbox NG!

I'm always interested to find a solution which is interesting for as many users as possible.

I'm not a DIY fanatic, instead I like the challenge to make unusual things happen.

 

So: thank you for triggering this initiative at the right time, I feel that it will become a MIDIbox standard device for the next years  :rofl:

 

Best Regards, Thorsten.

Link to comment
Share on other sites

:smile:  WOW I really really love the new step recording feature!!

 

For me it is perfect as it is implemented now :smile: :

temporary GP-hold, permanent SELECT

Also the midi learn for drum tracks makes live much easier!

 

Thank you very very much Thorsten!

 

But i once noticed a strange bug in V4_086_pre3 which I could no longer reproduce after repowereing the SEQ???

The live record function seemed to be messed up somehow:

-The chaselight automatically erased already recorded steps when passing them

-When entering the Record page all drum tracks hve been muted and unmuted when leaving record page

This was reproducable as long i did not repower my machine, now everything seems to work fine...

May be somebody else hase experieced something similar??

 

Best regards

Gridracer

Edited by Gridracer
Link to comment
Share on other sites

I'm glad that you are happy with the current solution :)

 

Today I did some finetuning & minor improvements (e.g. display clearly shows if you are in the "EDIT RECORDING" mode), record page can now also be entered by pressing EDIT+GP12 button, etc...

 

If somebody still notices imperfections, please check again with the final v4.086 release.

@Gridracer: sounds like Live recording was enabled, and some notes were incoming from an external device.

If this happens again check with the integrated MIDI Monitor if events are received over the MIDI port and channel which is selected in the Record page.

 

 

Complete ChangeLog for V4.086:

MIDIboxSEQ V4.086
~~~~~~~~~~~~~~~~~

   o MIDI Learn for Drum notes in Track Event configuration page:
     on a drum track, press & hold button GP12 to set the drum note
     depending on the configured recording port & channel (which has to be
     configured in the RECORD page)

   o Edit page: press&hold a GP button to record directly into the selected step

   o Edit page: config page which was previously visible by pressing the SELECT
     button now displayed by pressing&holding EDIT button.
     SELECT button now toggles step recording mode

   o Edit page: added shortcut to Recording Config (EDIT+GP11/GP12)

   o Record page now allows to toggle the FTS and FX flag for MIDI Forwarding
     (same flags can be configured in LIVE page)

   o Step Recording: note length measurements now also working correctly when
     the sequencer is clocked in slave mode.

   o Track Event configuration page: VelN/VelA not displayed if they are
     not relevant for the selected configuration.

   o Clear function will clear all selected tracks

   o LFO page: Extra CC can now be disabled/enable with a separate switch

   o Echo page: echo can now be enabled/disabled without touching the repeat value 

 

Best Regards, Thorsten.

Link to comment
Share on other sites

An update on the Novation Launchpad Mini experiment: I got the devices today.

 

The adaption shouldn't be so difficult, although we will miss the second half of the original BLM16x16+X, and MBSEQ will also be loaded much more due to the poor LED control protocol (even the "optimized" solution is multiple times slower than my own protocol, especially when LED rows should be updated vertically). However, since it's a USB MIDI connection, we would probably never noticed this...

 

But I've also bad news: the controllers won't work with a direct USB connection to a STM32F4 core due to three reasons:

 

1) MIOS32 doesn't support USB hubs, which means that only a single device can be connected directly. Adding support for USB hubs will be a challenge, because there isn't so much information available in the internet which would directly help. Developing it from scratch would result into too much effort, and the only open sources I found so far are in the Linux driver, but even this one needs some days & try & error to get it working.

 

2) even more annoying: a USB MIDI connection can't be established while connecting a single Novation Launchpad Mini to a STM32F4. The communication already stalls while STM32F4 tries to get the device descriptor. 

 

3) But not only that: this device is the first one that I've seen so far which uses isochronous transfers instead of bulk transfers for USB MIDI; transfers will only take place each mS instead of "as soon as possible".

Again a poor choice - I've no clue why this should make sense, e.g. data integrity is not guaranteed with this type of transfers (-> MIDI events can get lost)

 

However, considering these flaws I think that Novation devices shouldn't be accessed directly by a MIOS32 core, but only from a computer (Mac or (Micro-)PC).

And if a computer is involved anyhow, MBSEQ doesn't need to provide the remote device protocol directly, but it could still use it's own "optimized BLM protocol", and the translation to the remote device can be done externally.

 

Thinking a bit further I come to the conclusion, that I could simply implement the "translation" into the BLM16x16+X emulation app!

This might also add some more flexibility - let's see.

More updates on this topic this weekend.

 

Best Regards, Thorsten.

Link to comment
Share on other sites

That's unfortunate - the "signal every 1ms" is particularly weird...

 

Do you mean incorporating the translation into the windows/mac emulator program, or the lemur emulator?

 

I've been meaning to ask actually: Is the windows/mac program Juce-based?  Looking at the source in the blm_scalar_emulation directory, it seems like it probably is...  If so, is there any reason why it wouldn't be easy to compile for Linux?  I haven't tried yet, but I've been meaning to give it a shot and see if it works.

Edited by borfo
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...