Jump to content

midiphy SEQ v4+


latigid on

Recommended Posts

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.

 

893EF78A-D137-4897-8F82-DD6F3CD7A025.jpeg

  • Like 2
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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 by puristin
Link to comment
Share on other sites

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 ;)

Link to comment
Share on other sites

  • 2 weeks later...
  • 3 weeks later...

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?

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

@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 :)

bNbvCCW.jpg?1

 

Well done, #29! :cheers:

Many greets,
Peter

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 2 weeks later...
  • 3 weeks later...

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.

 

ypcQF7qdpaohd82lgtPSjJBH3rNOFQr9JudVCMie

  • Like 2
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...
×
×
  • Create New...