MIDIbox SEQ V4 Release + Feedback

[Hawkeye]

Holy moly, you release things faster than we can test :thumbsup:

Thank you very much for that feature!!!

*upgrading to .46*

Edit: a few hours later... just tested it - it is working really fine and is especially useful for moving tracks around into a more logical order, and is cool for quickly copying a full track with all settings and then modifying some notes for a variation... very good! :ahappy:

Edited August 1, 2011 by Hawkeye

[TK.]

4.047 is available:

MIDIboxSEQ V4.047

~~~~~~~~~~~~~~~~~


   o MIDIbox SEQ V4 is not beta anymore - but we continue to increment the

     version number and just leave out "beta" :-)


   o compiled for new MIOS32 Bootloader V1.005

     You can safely enable the "fastboot" option of the bootloader, so that

     the application starts immediately after power-on


   o for MBHP_CORE_LPC17: since this board doesn't provide a J5C connector,

     following signals are available at J28:

     - Clock: J28.SDA

     - Start/Stop: J28.SC

     - Gate 7: J28.WS

     - Gate 8: J28.MCLK


   o OSC Client/Server: support for TouchOSC protocol

[/code]


Best Regards, Thorsten.

[Gridracer]

Yuhu, beyond BETA! Just updated MIOS Studio, bootloader and application everything worked excellent!

Thanks!

And now its time to do some "testing" ;-)

Best Regards

Gridracer

[nuke]

nice... :frantics:;)

so me again, hehe ...

is it for purpose when in "move-mode"( where u can move single steps) , that every selected step after the first moved step switches to the note of the step before ??...so ie. selecting step 1 ( c#2 ) moving around works...then selecting step 6 ( b#4 )

becomes also c#2 when moving...maybe its a quick copy feature but i find it strange when u just want to "shuffle" some steps around...it works only when releasing the move GP-5 and reentering it for next steps.

sm:)e, nik

[mastomo]

upload is done !!!

everything is fine :ahappy:

Edited August 29, 2011 by mastomo

[TK.]

V4.048 is available for download now. :)

From the ChangeLog:

MIDIboxSEQ V4.048

~~~~~~~~~~~~~~~~~


   o CC and PitchBender values only send on value changes anymore to save

     MIDI bandwith on high-speed tracks


   o Step record: simplified usage of poly mode. Now the step is automatically

     cleared when all keys were released and new notes are entered.


   o Step record: duration (note length) will now be recorded as well!


   o Live record: some improvements for the "forward MIDI" option


   o MSD mode (SD Card Reader) can now also be enabled with the "msd" command

     in MIOS Terminal


   o Move step: doesn't overwrite new selection anymore

[/code]


Best Regards, Thorsten.

[vcfool]

Hi,

I upgraded from v041 to v048.

Something is wrong with my Drum tracks when played from an external MIDI keyboard: The Drum sounds appear repeated several times over the whole keyboard and some MIDI notes don't trigger the right sounds.

Using the Live Play mode works fine. Sequenced tracks also work nice. Just direct playing/recording from the external keyboard seems to be affected.

I just tried version 42 which is the last one I downloaded (but never really tried) and the problem is also there.

Maybe I am doing something wrong. I went back to v041 and all is fine again.

Thanks again!

Edited September 19, 2011 by vcfool

[TK.]

vcfool: drum recording mode has to be adapted to the most recent changes (TODO)

However, v4.049 provides following features:

MIDIboxSEQ V4.049

~~~~~~~~~~~~~~~~~


   o support for MIDI OUT4 and MIDI IN4

     Provided by MBHP_CORE_LPC17 module only.

     MIDI OUT4 is available at J4B.SD

     MIDI IN4 is available at J4B.SC


   o fixed USB issue under Win7 if the interface name hasn't been

     customized in bootloader

[/code]


Best Regards, Thorsten.

[TK.]

I realized that OUT4/IN4 was also activated for the STM32 core - the firmware could crash (resp. random things could happen) if MIDI events are sent to this port!

The bug is already fixed in this version: http://www.ucapps.de/mios32/midibox_seq_v4_050_rc1.zip

An update is strongly recommended if you are currently using v4.049!

Best Regards, Thorsten.

[midilab]

Hi Tk,

I have realize that from version 4.048 ahead the GP LEDs - GP_DOUT_L_SR - are not working anymore.

Im using just 1 DOUT on my midibox() for Dual Color Led, and thats my config:

# number of first and second DOUT shift register used for GP LEDs

GP_DOUT_L_SR 1

GP_DOUT_R_SR 2

# DOUTs for Dual Color option:

GP_DOUT_L2_SR 3

GP_DOUT_R2_SR 4

And also i have zeroed all the interface leds pins(since im not going to need on my layout)

##################################################

# LED assignments to DOUT pins

# SR = 0: LED disabled

# SR = 1..16: directly forwarded to DOUT pin

# SR = 17..24: forwarded to a 8x8 LED matrix

##################################################

# SR Pin

LED_TRACK1 0 0

LED_TRACK2 0 0

LED_TRACK3 0 0

...

...

Versions 4.047 above are working fine.

Thanks for all your work on this project! amazing live tool!

[TK.]

I'm sorry for this mistake!

v4.050 is available now:

MIDIboxSEQ V4.050

~~~~~~~~~~~~~~~~~


   o added LED functions for received MIDI IN/OUT events to MBSEQ_HW.V4


   o added BPM LED Digit function to MBSEQ_HW.V4

     A schematic can be found under http://www.ucapps.de/midibox_seq/mbseq_v4_bpm_digits.pdf


   o SR1 working again (programming error during MBSEQV4L merge)

[/code]


Best Regards, Thorsten.

[midilab]

... sorry erroneous use of this post...

Edited October 1, 2011 by midilab

[TK.]

I'm surprised about your statement!!!

Is version 4.050 working fine???

Best Regards, Thorsten.

[midilab]

I'm surprised about your statement!!!

Is version 4.050 working fine???

Best Regards, Thorsten.

Holy shit! you're fast!

Everything in order now with 4.050! thanks a lot for that!

PS: i was planning to start the development of a new button to use as a footswitch pedal to use it as a kinda of midilooper control thats the idea:

Pedal holded: rec mode on(without the rec screen)

2x fast pedal pressing: delete the track data

3x fast pedal pressing: copy the track data

4x fast pedal pressing: paste the track data

5x fast pedal pressing: undo track changes

if i get some progressing i let you know, i think this will be a great improvment for livers loopers and its not so complicated to programming.

Best regards!

[Hawkeye]

Just upgraded to .50... GREAT Changes! Thanks TK.! :flowers:

Poly recording feels much better now!

And thanks for the BPM LED display!

I am very, very pleased with the unit! :thumbsup:

After you implemented the BPM LED display, I just wanted to let you know, what was on my wishlist, which for me somehow logically belonged to it (wanted to implement that, when there was time)...

These ideas are not high priority at all, and I would first like to hear your comments, and if given a general "ok", I would gladly participate in coding them :-).

1) add a current step LED display for the active track. There are situations, where this would come in extremely handy, e.g. when in live recording "standby" mode, just before hitting the keys, or when unmuting tracks. It would require three more LED digits and could use the same matrix as the BPM LEDs.

2) add a visual matrix track position indicator... using two cheap 8x8 led matrix blocks (ca 3€ each) for 16 horizontal x 8 vertical leds. Aiming for a Matrix-film "falling characters" effect... It would visualize, in which relative-to-the-tracklength step position every of the 16 tracks is currently in. (8 leds vertical for each track, e.g. if step 3 of 16 is played, the second vertical led would lighten up on the respective track column). Maybe it could also use the 8 BPM LED matrix "back channel pins" and thus only require 16 dout pins?

3) add support for separate tempo encoder input pins, that would also accept the "fast2" flag (temporarily push to accelerate bpm changes) and connect to the fast2 line of the other encoders.

4) add a fourth BPM LED digit with a dot, for displaying e.g. "120.3" to visualize small tempo changes

.

One could nicely fill a full DOUT module with these tempo/position indicators:

8 pins for matrix "back channels", 4 pins for tempo led digits, 3 pins for active track-current step position led digits, 16 pins for matrix step position indicators.

I´ve attached a small mockup of how this "tempo/position" module could look like, but am unsure of power requirements (transistors?) for the expanded led matrix (8 x (4 + 3+ 16)).

Greets and best regards!

Peter

Edited October 8, 2011 by Hawkeye

[TK.]

I consider to add this to the next release, it's a simple enhancement

Best Regards, Thorsten.

[nuke]

hey , i have another feature request... maybe for future updates, but only if it makes sense and fun... ;)

in the fx section , theres the humanizer which now can "randomize" notes, vel/cc and length...but since the whole right screen is empty, wouldn´t it be cool to have the trigger layer "humanized" also?...maybe with a percentage-value like probability...

so it would be possible to have some nice variation with accent, slide , rolls, random value etc... each with it´s own amount...?!

...just another latenight-idea 8)

sm:le, nik

[Hawkeye]

All four requests?!? :frantics:

TK., did anybody tell you lately, that you are incredible? :flowers:

Greets!

Peter

[TK.]

V4.051 is available now:

MIDIboxSEQ V4.051

~~~~~~~~~~~~~~~~~


   o improved live-recording of CCs


   o warning is print on screen if poly recording selected on a track with

     only one (or none) note layer


   o Drum live/step recording: disabled mapping of drum instruments

     to keys C/C#/D/D#/... - it was too confusing.


   o BPM LED Digit function: added optional 4th digit to display the value after the dot


   o added optional LED digits to display the current step.

     Anodes require a dedicated Shift Register, the 3 cathode lines can be shared with

     the shift register which is used to drive the cathodes of the BPM LED Digits.


   o added optional BPM (Tempo) encoder.

     As usual the pinning can be configured in the MBSEQ_HW.V4 file

[/code]


All reported bugs should be fixed now!


I've to reject following feature requests:


2) add a visual matrix track position indicator... using two cheap 8x8 led matrix blocks (ca 3€ each) for 16 horizontal x 8 vertical leds. Aiming for a Matrix-film "falling characters" effect... It would visualize, in which relative-to-the-tracklength step position every of the 16 tracks is currently in. (8 leds vertical for each track, e.g. if step 3 of 16 is played, the second vertical led would lighten up on the respective track column). Maybe it could also use the 8 BPM LED matrix "back channel pins" and thus only require 16 dout pins?


Since I won't be able to re-use existing code, and since I don't really want to support features which I'm unable to test by myself, especially before every release (see the errors reported by Gridracer in this thread to see what I mean)


One could nicely fill a full DOUT module with these tempo/position indicators:

8 pins for matrix "back channels", 4 pins for tempo led digits, 3 pins for active track-current step position led digits, 16 pins for matrix step position indicators.


Note that the shift registers for anodes shouldn't be shared, as this would make the displays less bright (or even consume too much power)



I added following feature to the wishlist - it will be implemented soon (because I like it as well):


in the fx section , theres the humanizer which now can "randomize" notes, vel/cc and length...but since the whole right screen is empty, wouldn´t it be cool to have the trigger layer "humanized" also?...maybe with a percentage-value like probability...

so it would be possible to have some nice variation with accent, slide , rolls, random value etc... each with it´s own amount...?! 



Best Regards, Thorsten.

[Hawkeye]

Very, very cool! Thanks!!!

Hope to provide test results, soon!

Greets,

Peter

[nuke]

i noticed some strange behaviour when using CC´s as enventtype...the values are somehow jumping and affecting other steps too.

but this happens to version v50 also, dunno about versions before, haven´t tested yet.

looking forward for the new humanize features ;)

ok tested v51, v50, v49(the crashing version) all no good with CC events

v48 i don´t have , so couldn´t test this

v47 works flawless with CC´s

...maybe that helps a bit ;)

Edited October 18, 2011 by nuke

[Hawkeye]

Hi there,.

got all LED digits (Kingbright LED digits with shared anode - SA52-11GWA) parts yesterday and just started to build it, but I have a problem...

Wanted to first build the BPM display and have enabled it on shift registers

SR 9 - for segments with 220R resistors and

SR10 - for the common led-digit anodes, soldered in eight bridges instead of 220R resistors, using pins 7-4, as described in the pdf documentation.

Unfortunately, whenever I attach a LED digit to a shared anode 7, 6, 5 or 4 on SR10 and connect the segment pins to SR 9, all segments are constantly on (quite dim)...

When I change the BPM and its third digit switches (e.g. from 130.9 to 131.0 bpm), all LED segments get brighter... so, something is happening, but somehow it is messed up :) - the behaviour is also independent of which common anode pin I am using (as long, as it is 7-4).

What is most interesting, is that when I attach some LED digit segments directly only to the four pins on SR10, (also the anode, just wired up three random segments and the anode to pins 7..4 on SR 10), different segments are turned on, and stay turned on, when I change the BPM. So, clearly something is going on, but I don´t understand what :-) - could it be, that the anode/segment shift registers somehow have swapped behaviour?

Here is the config:

##################################################

# Optional BPM digits

##################################################


# set to 1 or 2 to enable the 3 optional BPM digits

# 0: BPM digits disabled

# 1: BPM digits with common cathode

# 2: BPM digits with common anode

BPM_DIGITS_ENABLED 2


# define the DOUT shift register to which the segments are connected (0=disabled)

BPM_DIGITS_SEGMENTS_SR 9


# define the DOUT SR and pin to which the common pins are connected

# we are counting from right to left

# Example: 140.5 BPM: (COMMON1 = .5, COMMON2=0., COMMON3=4, COMMON4=1)

#   					SR  Pin

BPM_DIGITS_COMMON1_PIN   10   7

BPM_DIGITS_COMMON2_PIN   10   6

BPM_DIGITS_COMMON3_PIN   10   5

BPM_DIGITS_COMMON4_PIN   10   4

Thanks for any help!

Greets,

Peter

Edited October 21, 2011 by Hawkeye

[Hawkeye]

Hi Thorsten,

just continued to test... and found some things, that may explain the strange behaviour on my side...

a) applying the inversion mask for a "pin" probably will not work (in case of shared anodes and inversion):

unsigned char mask = 0xff;

printf("%u", 1 ^ mask);

yields 254 instead of 0 (app.c, lines 256ff)

b) for the fourth digit, a float bpm is needed to render it successfully:

the code was

int bpm = (int)SEQ_BPM_Get();

...

u8 sr_value = SEQ_LED_DigitPatternGet((bpm*10) % 10);

c) somehow the configuration of the segments register needs to be one value smaller than it is... i need to set BPM_DIGITS_SEGMENTS_SR 8, when it is 9... the register for the BPM_DIGITS_COMMONX_PIN is all right.

Am not sure, if these observations are right, still testing, but I start to see numbers on the breadboard :-)

Greets and have a fine weekend! Thanks for adding these features, again :)

Peter

Edit2: just saw in the code, that the currently edited step is displayed in the step display... uh- sorry, my fault, the feature request was ill-formulated... i meant the currently played step in the active pattern, when the sequencer plays... so that you know when to expect a track border... sorry for being such a pain in the ... :-)

Edited October 21, 2011 by Hawkeye

[TK.]

i noticed some strange behaviour when using CC´s as enventtype...the values are somehow jumping and affecting other steps too.

but this happens to version v50 also, dunno about versions before, haven´t tested yet.

looking forward for the new humanize features ;)

ok tested v51, v50, v49(the crashing version) all no good with CC events

v48 i don´t have , so couldn´t test this

v47 works flawless with CC´s

...maybe that helps a bit ;)

Oh man, thats clear - I added a CC bandwidth optimization (mainly for MBSEQV4L) and forgot to disable it when CC values should be displayed on screen.

I haven't noticed this as I only tested the changes on MBSEQV4L (without LCDs...)

A new version will be available this evening.

Best Regards, Thorsten.

[TK.]

MBSEQ V4.052 is available now:

MIDIboxSEQ V4.052

~~~~~~~~~~~~~~~~~


   o bugfix: CC values were influenced when they were displayed on the edit page


   o Hawkeye fixed the BPM/STEP digits output and added a "TPD" (track position

     display) option for those who like to add more blink to their MIDIbox!

[/code]


Hawkeye: you might want to make your latest video public so that people can see how the TPD is working :)


Best Regards, Thorsten.