midiphy SEQ v4+

[momelq]

Build done! I tried a blue/yellow/white color scheme, by combining the red+green with one 47R resistor and the blue with 1k... it has become more a blue/orange scheme.

However, I am impressed by the perfection of this kit, with even spare parts and the case fits 100%, no need to drill additional holes.

 

[latigid on]

Congrats #27! Looks like a groovy colour-scheme and thanks for the kind feedback!

EDIT and beer (?) ! 

 

Edited April 13, 2020 by latigid on

[Hawkeye]

Cheers, very nice progress @chnuk and @momelq !

Hope you will have lots of fun with your new v4+s - they are awesome! :)

Many greets,
Peter

[SimonSays]

I’m slightly embarrassed to admit that I’m only just getting round to fixing the missing OTG jumper from my build :/

But not as embarrassed as I am to admit that I can’t find the correct location and/or position for the jumper! I went back through all the info I could find on it, but it’s obviously so simple that nobody has described where and how to position the jumper.

When i` removed the side panel to access the board and jumpered the visible headers (thanks for the tip @Adam Schabtach), I just got unit resets. Possibly, I have another problem, but can someone post a quick pic of the OTG jumper so I can rule that variable out?

thanks!

[latigid on]

Here you go! Please don't short the (typically unpopulated) J3-6 headers for (+5V supply buss).

 

The next run of PCBs will have the polyfuse added, thanks Adam for the research and suggestion!

 

[SimonSays]

Oh - for the love of god... the board is labelled. My embarrassment is complete and I am going to go and sit facing the wall and think about what i have done.

Thanks for being kind, @latigid on :)

[puristin]

While using SEQ V4+ to upload sysex patches to my synths, I noticed possible bug in the IIC1-4 midi output. If I send a single voice patch (142 bytes), for example, to Yamaha TX81Z, everything works. However, if I send larger bank patch (4104 bytes) IIC outputs do not seem to work. Receiving synth not to accept sysex, but unfortunately synth do not display any error in this case to debug this any further. If I change output port to OUT1-4, everything works as expected for both sizes of sysex.

Have anybody else experienced similar problems? Could there be some data corruption problem in the IIC firmware with larger sysex dumps?

Edited April 22, 2020 by puristin

[latigid on]

Could be a buffer size thing but you should start a new topic, try to e.g. record the output with MIOS Studio (set up the router) or through a utility like MIDIOX or so. Try also to delay the transmission rate?

[Antichambre]

IIC output is using 2 buffers, the STM buffer set to 1024, the 16F84 buffer which sized to 96 bytes.
I'm not sure but IIC is faster than MIDI then for a file size of 4104 bytes the STM will send 1024 bytes at a time and the PIC will overflow, not because of buffers sizes but just because it can't forward the data fast enough.

To check but the buffer of the PIC can't be bigger... You can try to reduce the speed of the IIC but not too much cause it will delay all messages, just enough to avoid overflow.
Or the best idea is to use a regular MIDI Out for your Yamaha FM ;)

[latigid on]

Nice!

[manu]

And I also finished my build 

Edited May 2, 2020 by manu

[latigid on]

Well done #28! 

[manu]

Thank you @latigid on! It was an awesome process to build the kit. 

(And that was probably the fastest assignment of a serial number in the history of manufacturing)

[manu]

Serial number installed 

Edited May 2, 2020 by manu

[latigid on]

:-)

[Adam Schabtach]

I've been having a good time with my sequencer lately, digging in to the arpeggiator and random-generation functions for the first time. I am puzzled by one thing, though: the FAST feature seems to do nothing. The button lights up when I press it, and it also lights up when I press the encoder switches, but this doesn't seem to have any other effect at all. The values seem to change at the same speed regardless. What am I missing?

[latigid on]

There's a few settings in the HWCFG to check e.g. (search "fast")

# the speed value for GP encoders which is used when the "FAST" button is activated:
ENC_GP_FAST_SPEED 3

# Auto FAST mode: if a layer is assigned to velocity or CC, the fast button will be automatically
# enabled - in other cases (e.g. Note or Length), the fast button will be automatically disabled
ENC_AUTO_FAST        1


# the speed value for the BPM encoder which is used when the "FAST" function is activated
ENC_BPM_FAST_SPEED 3

 

Can you check if altering these changes things to your liking?

Of course, some features might have been "broken" by hard-coding functions. In the Wilba SEQ version, there was one common fast button, no matter what encoder was pressed. In the v4+ we have all of the encoders on dedicated DIN inputs (matrix) to allow for different customisation. 

[Adam Schabtach]

Thanks. The settings in my HWCFG file were the same as you listed. I also verified that the setting which affects whether the FAST mode is activated momentarily by holding down the encoder, or toggled on/off by clicking the encoder, works as expected. However, the ENC_BPM_FAST_SPEED setting still has no effect. I changed it from 3 to 10 and rotating any GP encoder by one click still always produces a change of +1 or -1 of the associated value, whether or not the FAST button is illuminated.

[latigid on]

Sounds like it could be a software bug, in which case the following thread is the place for it:

http://midibox.org/forums/topic/13137-midibox-seq-v4-release-feedback/?page=61

[Hawkeye]

@Adam Schabtach i did some tests of the acceleration feature when the v4+ was released and just tested again. In short words: it works in the v4+ as it worked before on the v4 - that's also the behaviour people are used to by now.

A bit of historic context - please correct me, if i am wrong - back in the olden MIOS8 days, TK. developed the MBSID application which performs automatic encoder acceleration based on the speed the encoder is turned - slow turning speed = no acceleration, quick turning speed = active acceleration. That's the only way to enter the many different levels of e.g. the SID filter cutoff value ranging from 0x000 - 0xFFF = 12 bits of resolution. Thus you could fine-tune the filter cutoff by slowly turning the filter knob, and quickly change it by quickly turning it - a method that works really nicely. The MB6582 encoder as the v4+ encoders also "only" has 24 pulses per 360° turn, so not many pulses available to adjust a high-res 14-bit value.

From this behaviour, the MBSEQ encoder acceleration (which was also available first on an 8-bit platform) was derived. It might have also been the other way around, MBSEQ 8-bit first, then MBSID :). Anyways - the acceleration even nowadays is only active, if you turn the encoder quickly.

Now to describe, what FAST does: it changes the speed of acceleration. If you do this experiment: quickly turn a SEQ v4+ encoder changing a note value by a half turn, starting from a low value note, e.g. C-1. Doing this, i get to D#2. Now repeat the process but push the knob down while doing it, now i get from C-1 to C#3, the FAST button LED is also backlit when doing the latter. You can fine-tune the speed when accelerated in the HWCFG as Andy described. E.g. for a more prominent effect, it might be good to tune to something like

ENC_GP_FAST_SPEED 7

Still you need to push down the knob and turn quickly for acceleration to be effective.

Sorry for this long description, but i think a bit of historic context helps to understand why this function works as it does :).

Best regards,
Peter

[Hawkeye]

@mcmurray has completed his unit - just for the sake of completenesss in this thread, i've copied his post over to this thread - the original was in the SEQ v4+ Troubleshooting thread:

Quote

 

Apologies for the late reply (been busy af with work) but here's mine for a serial number - I hope this is the right place to get one, if not let me know where I should post it. This was such an enjoyable build I'm considering a Loopa :)

 

Well done, #29!

Many greets,
Peter

[Adam Schabtach]

7 hours ago, Hawkeye said:

Sorry for this long description, but i think a bit of historic context helps to understand why this function works as it does :).

Thanks for the explanation. The challenge that those of us with little or no prior experience with MIDIbox in general and the sequencers in particular is that we're often left puzzled by certain operational details, such as this one. As far as I can tell, the only documentation for this feature is "FAST - Use this button to speed up the encoder and datawheel increments/decrements." That doesn't tell me that I also have to rotate the encoder quickly. All other devices I've used work one way or the other: either there's built-in acceleration so rotating the knob faster increases the value change per click, or there's some sort of switched behavior (like pressing the encoder) which changes the value change per click. Hence I didn't expect the v4+ to require both gestures to change its behavior. Anyway, at least now I know what to expect.

Encoder acceleration is a tricky thing to implement well. I've tried a couple of different approaches in my own projects and to get it to work really well usually involves scaling the acceleration based on the range of the target parameter. Of course this means designing and implementing a parameter-management system, too...

Thanks--

--Adam

[modus0perandi]

btw, the FAST button will also make "mute" happen immediately even if its set to mute on measure. :)

[audax_axon]

Have completed this build. What a great project - the new case and overall integration is truly excellent!

Major props to all the folks here who put this system together, Hawkeye, latigid on, thanks to Antichambre for the custom keycaps - and of course TK for creating the MB world.

 

[Hawkeye]

@audax_axon Cheers and thanks for your kind words!
I mostly only had a camera rolling while soldering some parts - all the props for the v4+ go to @TK., @latigid on and @AdrianH! :)

Hope you enjoy your official SEQ v4+ build number #30! :)

Best regards,
Peter