686 replies to this topic

[TK.]

Thanks for reporting this!
MIDI IN wasn't working due to a stupid copy&paste error in the MIOS32 driver (seems that I need an automated regression ;-))

MIDIboxSEQ V4.053
~~~~~~~~~~~~~~~~~

   o bugfix: MIDI IN ports are working again on MBHP_CORE_STM32 build

The error message is probably caused by a syntax error in your MBSEQ_HW.V4 file.
Could you please send me the file for further analysis?

Best Regards, Thorsten.

[xarolium]

Hi Midiboxers,

Thank you TK to fix MIDI In Bug

I would like to know if its possible to improve IMPORT MIDIFILE fonction.
Like you describe on the V4.0Beta19 when you import midifile every note came with the same lenght. Do you think it's possible to change it that when i import my MIDIFILE i keep the lenght note i edited on my Software sequencer.
I don't know if it's clear what i'm trying to explain
Sorry for my Frogy english

Xarolium

Edited by xarolium, 31 October 2011 - 10:20.

[Hawkeye]

Ok, I really hesitate to ask, because sooo much was added already... but there would be one little thing to improve it in my eyes

Would it be possible to add a configuration switch, that allows to change the behaviour of the datahweel from the default "note editing behaviour" to "scroll behaviour" in edit mode for long-pattern-lovers :-) ?

Normally, the current step note is changed, when the datawheel is used, but for that, the step encoders are also very good.
It would be great to scroll through the track/change the currently edited step number with the datawheel (kind of like scrub, but when it is not playing and without pushing any other button).
So that one can quickly access/see different parts of a track... It would be an immense time-saver for me (the cursor keys are already totally run down ).
I know, that one can use step view and then one of the GP buttons to jump to that section, but the datawheel for scrolling would be very intuitive for me...

Thanks, greets and have a great time!
Peter

Edited by Hawkeye, 31 October 2011 - 19:07.

[TK.]

I would like to know if its possible to improve IMPORT MIDIFILE fonction.
Like you describe on the V4.0Beta19 when you import midifile every note came with the same lenght. Do you think it's possible to change it that when i import my MIDIFILE i keep the lenght note i edited on my Software sequencer.

Unfortunately this won't be possible, because each track has only a single length layer.
The whole MIDI event handling is based on this (e.g. to handle special cases correctly, such as notes which are longer than a step, or sustain flag enabled), so that I don't see a solution to solve this without writing a completely different sequencer engine (with limited edit capabilities).

Note that this is the reason why common MIDI sequencers (like Yamaha RM* or Korg Electribes) are so inflexible in step processing, because they store sequences in a stream based format where every note has an individual length, but where it's almost impossible to change the track direction, or to repeat a step, etc... without consuming a lot of CPU power.

In fact some time ago I hacked a stream based track mode into the firmware, but never released it since some existing features wouldn't work anymore, and since the required changes in the editor would take too much effort. Meanwhile the code has been removed...

Note: you could use the integrated MIDI file player if you only want to playback such a sequence which has been edited on your software sequencer.

Would it be possible to add a configuration switch, that allows to change the behaviour of the datahweel from the default "note editing behaviour" to "scroll behaviour" in edit mode for long-pattern-lovers :-) ?

I already considered this possibility, and I think that I should even enable it by default (behaviour could be changed by pressing SELECT button and switching an option)
Another option could be to use the datawheel for switching between parameter and trigger layers (especially useful in drum mode).
Since I'm not the only one anymore who misses this quick navigation capability, it will be added soon!

Best Regards, Thorsten.

[Hawkeye]

Thanks! Tell me, when you are in need of a new crate of beer, i´ll bring it over

[nuke]

hey...

i realized that echo fx on a track doesn´t react to grooves anymore...wasn´t that working before?

greets, nik


...mm... back on v47 (just for testing) now i´m pretty unsure, if it ever was working with grooves!?
maybe i never noticed it, since never used it so excessive like i did yesterday... hehe

Edited by nuke, 02 November 2011 - 12:44.

[gomiboy99]

Hawkeye, on 31 October 2011 - 18:01, said:
Would it be possible to add a configuration switch, that allows to change the behaviour of the datahweel from the default "note editing behaviour" to "scroll behaviour" in edit mode for long-pattern-lovers :-) ?


I already considered this possibility, and I think that I should even enable it by default (behaviour could be changed by pressing SELECT button and switching an option)
Another option could be to use the datawheel for switching between parameter and trigger layers (especially useful in drum mode).
Since I'm not the only one anymore who misses this quick navigation capability, it will be added soon!

Is this another way to go left and right? Or will it replace the Scroll function? I think it would be good to have a left right function on the datawheel. It frees up a couple of buttons on the front panel.

Tk, thanks for the excellent work.

Regards

Tim

[TK.]

i realized that echo fx on a track doesn´t react to grooves anymore...wasn´t that working before?

It works at my side, and I'm sure that it was also working before, as I use this combination in many of my own tracks

Or do you mean, that echoed events should take care about the groove? Thats impossible.

Is this another way to go left and right? Or will it replace the Scroll function? I think it would be good to have a left right function on the datawheel. It frees up a couple of buttons on the front panel.

We could use it for both: scrolling the cursor and switching to the next page if the cursor reached the boundary.
This would be the most perfect usage, as in most cases the page wouldn't be switched immediately if you move the datawheel (e.g. by accident)

Best Regards, Thorsten.

[gomiboy99]

That is the exactly what I meant to say.

[TK.]

I've committed the changes into the repository for beta testers!

Personally I will prefer to use DATAWHEEL_MODE_SCROLL_CURSOR, therefore it's default.

Following modes are available:

    const char datawheel_mode_str[DATAWHEEL_MODE_NUM][11] = {
      " Cursor   ",
      " StepView ",
      " Value    ",
      " ParLayer ",
      " TrgLayer ",
    };

The mode can be selected by pressing SELECT + GP7 (decrement) or GP8 (increment)

Note that the Up/Down buttons of Wilba's CS have the same function which is assigned to the datawheel.

Best Regards, Thorsten.

[Hawkeye]

one word: fantastic
tested all modes (all are working fine) - for me it´ll clearly stay in "Cursor mode"
Thx!!!

Edited by Hawkeye, 02 November 2011 - 23:53.

[nuke]

Or do you mean, that echoed events should take care about the groove? Thats impossible.

yep...thats what i meant...
i just noticed a "rolling" with overlapping notes and echos, when using heavy shuffles with 16th echoes...
ok...won´t work ...is it because of different/mixed timesignatures that it can´t be snapped into groove grids?


...btw. i think i found another bug:
i get a crash with "!! HARD FAULT !! at PC=0x0802fc3e , when trying to save track-presets.
i can load my previous presets just fine,i also can save and load pattern and sessions without problems...
only saving presets gives me that crash, have to switch off and on then...

greets, nik

[TK.]

yep...thats what i meant...
i just noticed a "rolling" with overlapping notes and echos, when using heavy shuffles with 16th echoes...
ok...won´t work ...is it because of different/mixed timesignatures that it can´t be snapped into groove grids?

yes - the echo will start once the delayed note is triggered like an audio echo.

...btw. i think i found another bug:
i get a crash with "!! HARD FAULT !! at PC=0x0802fc3e , when trying to save track-presets.

Classical buffer overrun, the fix is now available in the repository.

I also integrated a new footswitch extension implemented by Midilab which allows to enable live record mode from any page, delete a track by tapping on the switch, and more (in future)

Best Regards, Thorsten.

[Gridracer]

HI,
I am already curious about the next features

and i also have one in mind, may be you like it, and perhaps it is feasible:

I guess it would be nice if a parameter change with a GP encoder in edit mode would
NOT be applied immediately AS LONG as you hold the edit (or slect?) button depressed.

By this way you would not hear the scrolling through the note values during live editing if desired.

Best Regards

Gridracer

[TK.]

and i also have one in mind, may be you like it, and perhaps it is feasible:

I guess it would be nice if a parameter change with a GP encoder in edit mode would
NOT be applied immediately AS LONG as you hold the edit (or slect?) button depressed.

As long as only a single value should be handled this way, I could add this to the firmware without much effort.
But once you want to change multiple values (also triggers) and take over them by releasing the EDIT button, the effort would be too high.

Your choice? ;)

Best Regards, Thorsten.

[Gridracer]

As long as only a single value should be handled this way, I could add this to the firmware without much effort.
But once you want to change multiple values (also triggers) and take over them by releasing the EDIT button, the effort would be too high.

Your choice? ;)

Best Regards, Thorsten.

Hi, I was just thinking of one single value for only one step
and if it would only work for note and chord number it would be sufficient for me, that would avoild "disharmonics" during editing
I think an editbuffer for serveral values would be some overkill

Happy to hear that it would be not much effort and Thanks a lot if you could add it :-)

Best Regards

Gridracer

[TK.]

and if it would only work for note and chord number it would be sufficient for me, that would avoild "disharmonics" during editing
I think an editbuffer for serveral values would be some overkill

I'm glad to hear this, because while implementing the mode I noticed a big problem: the display routines take values based on complete events provided by the sequencer engine instead of directly accessing the parameter layers.
This has the big advantage, that there is a lower risk of incorrectly displayed values if I'm doing a programming error in all those if/else/if/else branches (spaghetti code...)

So, I will limit the feature to notes/chords and change the code accordingly to avoid any "it mostly works, but under this special condition it doesn't..." bug report.
I can only say: I know that it will never work perfectly!

Best Regards, Thorsten.

[TK.]

Alright, V4.054 is available now:

MIDIboxSEQ V4.054
~~~~~~~~~~~~~~~~~

   o in edit page the datawheel can now be used for different purposes:
     it can scroll the cursor, the step view, can change the value (as before)
     and it can be used to select the parameter/trigger layer.
     The function can be selected by pressing SELECT + GP7/8

   o Rômulo aka. Midilab started to implement a footswitch function which
     is especially useful for live recording and track modifications while
     playing on a keyboard.
     Press&Hold the footswitch to enable record mode, release it to disable
     record mode.
     Tap the footswitch shortly to delete the track.
     The footswitch can be assigned to a free DIN pin in MBSEQ_HW.V4

   o note and chords can now be edited without immediate change by pressing&holding
     the EDIT button. The new value will be taken over once another step is
     edited, or the EDIT button is released.

   o fixed potential buffer overrun when preset is stored

Best Regards, Thorsten.

[midilab]

Hi Tk,

I got a request that i think isnt that hard to implement.

Something that can be preatty usefull for live situations is some kinda of delay time param for the midi data on each specific port.

Something like the "delay" we got inside ableton live to get things in time if we need to compensate some kinda of lag, or just to get a different groove shifting the time of midi data on ports.

Example:

Utils -> Opt -> Midi delay

Port Port
USB1 OUT1
-3.4 ms 2.4 ms

if it is possible to save that config inside session data will be perfect, because sometimes you need that kinda a configuration for diferent sessions and setups.

Thanks in advance!

Edited by midilab, 29 November 2011 - 21:48.

[TK.]

Hi,

I got a request that i think isnt that hard to implement.

Unfortunately this is hard to implement - resp. if I would change the sequencer engine to cover this request, it would have a disadvantage on MIDI timing accuracy (which I find more important than such a feature)

Background: in distance to common MIDI sequencers running on a PC, the event handler of MBSEQ doesn't schedule MIDI events based on time, but based on the MIDI clock tempo.
This results into a higher accuracy. This also allows to change the tempo during runtime without re-scheduling MIDI events (especially important for MIDI Echo Fx)

As a side-effect, the granularity of the scheduler interval is independent from the time. It isn't possible to delay events with uS accuracy, only with "midi tick" accuracy, which depends on the tempo, and which is higher than 1 mS (e.g. at 120 BPM with 384 ppqn, it's ca. 1.302 mS, at 140 BPM it's ca. 1.116 mS)

For a high accuracy and stable delay compensation, I recommend the usage of audio delays!

Best Regards, Thorsten.