[downerczx]

Hello,

I am wondering if it is able to control the type arpeggio in a patch from a midi controller. I.E. If I push a button or hold a controller up then the notes ascend, if I go down, it descends, right does back and forth and left does random... or the like.


Is something like this possible over midi? I can only find arp speed and gatewidth...

thank you

[m00dawg]

I don't see that function as being available either using NRPN or CCs, though I only took a brief look.

So currently the answer seems to be no, although it may be possible to add this by making some firmware changes. Or perhaps it is something already in the works for MBSIDv3?

[Hawkeye]

It should be possible to upload a complete patch, but this would require some more work and logic on the controlling side.

Workflow:
* download + memcache current patch (needs to be only done once, as long as the user does not change settings on the frontpanel, which emits midi ccs and indicates that the cached version should be thrown away).
* change patch settings, that are not directly controllable via midi in the cached patch buffer
* upload patch via sysex

That is how Rutgers Java based editor works.

Greets,
Peter

This post has been edited by Hawkeye: 05 January 2012 - 15:26

[m00dawg]

It sounded like he was wanting to change the behavior in real-time though? I thought the patch handing for MBSID had already been done (as in if you change a parameter, it just changes the patch state in RAM, not in flash until you save it)?

[Hawkeye]

Yes, i meant upload the changed patch to the memory buffer of the MBSID (not bankstick). That is close to realtime, although not as quick as a dedicated CC, of course :-).

[m00dawg]

*oh* now I see what you're getting at. Hmm yeah that's an interesting way to do it!

[Hawkeye]

Yes, this is how it works for some synths with very many patch parameters, e.g. the FS1R...
Problem though is, you need a little bit moar logic - especially filter other midi events while the dump is uploaded to the synth memory buffer, otherwise it could get corrupted (at least I had problems with it).

Greets,
Peter

[TK.]

MBSID allows to directly change any parameter via SysEx without loading and writing back the (huge!) patch buffer.

See the SysEx documentation: http://svnmios.midib...lementation.txt

  06/a) F0 00 00 7E 4B <device-number> 06 <WOPT> <AH> <AL> <value_l> <value_h> F7
        Direct Write of parameter into patch buffer (<AH> = 0..3, <AL> = 0..7F)
        Patch address: (<AH> << 7) | <AL>
        <WOPT>: options to speed up communication with editor, behaviour depends on engine
        See topic "Direct Write Options" at the end of this document

Arp parameters:

0x06c | Arp Mode
      | [0] 0=Arp disabled, 1=Arp enabled
      | [3:1] Direction: 0=up, 1=down, 2=Up&Down, 3=Down&Up, 4=Up&Down 2, 5=Down&Up 2, 6=random
      | [4] Sorted
      | [5] Hold
      | [6] Sync with keys
      | [7] CAC (Constant Arp Cycle)
0x06d | Arp Speed Divider
      | [5:0] Clock Divider (0..63) (derived from global clock)
      | [6] Easy Chord
      | [7] Oneshot
0x06e | Arp Gatelength and Range
      | [4:0] Gatelength (0..31)
      | [7:5] Octave range (0..7 = 1..8 octaves)

By using the WOPT feature it's possible to update the arp parameter of all oscillators and SIDs with a single SysEx command.
(see end of the document for a more detailed description)

Rutger's MBSID Editor uses the direct access as well, therefore parameters are quickly updated.

This also means, that the most simple way to find out the SysEx string that you need to send is to monitor the output of the MBSID Editor when you are changing a parameter.

Best Regards, Thorsten.

[Hawkeye]

Very nice feature - I stand corrected regarding the full buffer update!

This post has been edited by Hawkeye: 05 January 2012 - 19:54

[m00dawg]

Hah I, too, forgot you could do that Oops.

[downerczx]

Wow, this is awesome. Thanks TK. I can't hardly wait to implement it!

However, my sammichSID just went crazy. The screen is one green bar. I'm trying to track down the problem right now. Everything boots up okay, but then... the bar. It was working fine when I was on vacation, but when I flew home and turned it on... green bar. Any ideas?

If I get it working and make the patch, I will share it... though I don't know if it will be of use to anyone.

[m00dawg]

A green bar can indicate your LCD might not be getting data, so check the pins that connect the LCD from the base to the control surface first (you can sometimes coax them into being naughty or nice by pushing on the board around those connections a little). You can also check to make sure the synth itself is working by trying to play notes and things to see if that works. If they do, you know it's probably something to do with the LCD.