MIDIbox SID V2 Release + Feedback

[TK.]

RC24:

[tt]

  o voice allocation of multi engine working again

  o Lead engine: MdW (ModWheel) and Key modulation source now provide a value in

    positive range only

  o overworked oscillator pitch handling: now completely linear frequency

    calculations.

    Advantages:

      - modulation frequency (e.g. LFO vibrato) independent from oscillator frequency

      - accurate filter key tracking

      - the O2A option (forward pitch to AOUT) doesn't result into out-of-scale

        SID frequencies anymore

  o the presets under presets/v2_vintage_bank.syx have been overworked according to

    the new osc frequency handling

[/tt]

Following sound samples demonstrate the difference between the old and new oscillator pitch modulation handling:

Old handling: with higher frequencies, the LFO modulation of the pitch got less "intensive"

http://www.ucapps.de/mp3/midibox_sid/mbsidv2_lfo_nonlin_osc_frq_mod.mp3

New handling: same "intensity" of the pitch modulation independent from the OSC frequency:

http://www.ucapps.de/mp3/midibox_sid/mbsidv2_lfo_lin_osc_frq_mod.mp3

Please update your preset bank!

Best Regards, Thorsten.

[stryd_one]

      - modulation frequency (e.g. LFO vibrato) independent from oscillator frequency

      - accurate filter key tracking

      - the O2A option (forward pitch to AOUT) doesn't result into out-of-scale

        SID frequencies anymore

OH AWESOME!

[TK.]

And again a new version (RC25) with fixed SusKey behaviour

Razmo is currently doing a lot of checks beside of bringing up his Soundforge based editor.

Here a demo of some really punchy patches (created & manually played by Razmo)

http://www.midibox.org/users/razmo/mbsidv2_PatchTest.mp3

Best Regards, Thorsten.

[Pascal]

WTF! I want this patches!

[Sasha]

Razmo, those samples sounds nice! :) Thanks for publishing it Thorsten.

[Matrix12x]

Those patches are great and punchy. I can't wait to build my MIDIBOX SID!!

[Goblinz]

Nice patches... especially the one starting at 35 seconds, I can see me using this (or at least attempting to use it). Can't wait to get my SID finished.

          G

[ris8_allo_zen0]

I have to report two issues related to 2x16 LCD display:

• Reading in the manual I casually discovered the "Dump" option in the Shift menu. I can't see it because my LCD doesn't display it and I can't scroll to it because the menu encoder works on the parameter previously selected before pressing SHIFT. Is there anything that can be done? (i don't need it so desperately, but who knows in the future...)
  
  
• While displaying the special "parameter assignment" page, part of the parameter string falls outside the LCD range, especially the oscillator/lfo/env number which is quite important.
  My proposal: for 2x16 displays only, sacrifice the | character and the space between the first string (defined in sid_par_table.inc) and the second one (created in sid_lcd.inc). In the latter one, eliminating the # character and shortening some long variants if needed.
  

Many thanks!!

Greetings, RAZ

[ris8_allo_zen0]

While enjoying this great synth (and taking my chance to learn piano), I think I discovered a bug in rc25.

Steps to reproduce:

1- activate the Multi engine

2- enable the "meter" led matrix mode

3- press some keys on your keyboard

You'll see that all 6 oscillators are working in turn.

4- enable the arpeggiator

5- press at least a key once

You'll see only one oscillator working, as expected (Multi engine can't work with the builtin arpeggiator).

6- disable the arpeggiator

7- press some keys on your keyboard

You should see 6 oscillators, but only 5 work. The one chosen for arpeggiator doesn't participate anymore.

If you repeat steps 4 to 7, you'll see other oscillators not working anymore, until monophony.

Some workarounds:

- change the engine and return to Multi.

- restart the synth.

- press six keys at the same time.

Best regards, RAZ

[TK.]

Unfortunately it isn't possible to solve this arpeggiator switching properly due to conceptional reasons.

The special handling of an arpeggiator in multi mode was already an unplanned add-on which required a lot of branches to get it working properly.

You are saying that "Multi engine can't work with the builtin arpeggiator".

This is wrong - instead, it should work perfectly with the multi engine! The voice handling is similar like for mono instruments to ensure, that an arp is always played by the same voice and arp sequencer, so that up to 6 different arpeggio instruments can be played in parallel over different MIDI channels or keyboard zones with dedicated sounds.

I spent a lot of time to get this working, but it was clear to me that the current implementation isn't a proper solution...

Covering the "turn off arp" case properly would require an indicator in the voice queue which stores, how the voice is/was used. It would consume additional CPU cycles when searching for a free voice etc... I think that it isn't really worth the effort to fix this.

Instead I think, that the listed workarounds are fine ;)

Best Regards, Thorsten.

P.S.: I will think about a better 2x16 LCD support sooner or later, but for me this is a minor issue, there are currently much more criticial bugs, e.g. sometimes the engine is so overloaded, that this results into hanging notes.

I already consider to remove or disable features in order to overcome this

[ris8_allo_zen0]

Thanks TK for the explanation. I tried the arpeggiator with split keyboard just now. It's fantastic!!!

Best regards, RAZ

[dj3nk]

Is there a way to integrate analog multiplexing? If this can't be integrated in a future RC, is it integratable by hand?

EDIT: Perhaps the slave cores could "share" the analog inputs somehow ?!

[TK.]

No, the application uses its own ADC scanning routine which isn't extendible for analog multiplexers.

Also the inputs of the slave cores cannot be scanned by the master core (event propagation from slave to master would lead to a performance loss)

Best Regards, Thorsten.

[Jurbo]

I have spent a couple of hours toying around the MBSID V2 - I'm slowly starting to understand the workings of  it after upgrading from V1... This thing has seriously multiplied in capacity! The available ways to mangle the sound of the poor old SID are beyond belief! I had barely scratched the surface of the MBSID V1, thinking how versatile it was - and now I have this new beast in my hands... It's simply amazing!!!

Thorsten - your work is simply fantastic! Maximum respect!  8) 

[puddingbrumsel]

Hi TK,

is it possible to get a MidiClock-Signal on the supported Midi-out ? I wonder why there is no clock as the sid can be used as a drumsynth with TR-like-sequencer. And internal the clock is already available. So the SId can act as a real midi-master.

best regards

[TK.]

Jurbo: thank you! :)

Puddingbrumsel: I could add a MIDI clock output, but there is a high danger that it will jitter, as the events have to be sent from a low priority task, while the internal synth is running on a high priority task (which isn't allowed to send MIDI...)

So, under such circumstances, would it really be useful, or wouldn't it be better to use an external master for synching all your MIDI devices from the same source?

Best Regards, Thorsten.

[puddingbrumsel]

Puddingbrumsel: I could add a MIDI clock output, but there is a high danger that it will jitter, as the events have to be sent from a low priority task, while the internal synth is running on a high priority task (which isn't allowed to send MIDI...)

So, under such circumstances, would it really be useful, or wouldn't it be better to use an external master for synching all your MIDI devices from the same source?

you're right TK. I remembered another answer from you in another thread. So i decided to add a midi-thru to my sid. Shoud be the better choice. Thanks

[TK.]

RC26 is available now.

It contains some improvements for Super Poly mode and SysEx distribution via CAN

Best Regards, Thorsten.

[renepela]

Could it be you forgot to change the version number? I uploaded RC26, but after the reboot it still shows version RC25 on my display.

I use Setup_mb6582.hex

By the way: What is the difference between setup_mb8580 and setup_mb6582? The 6582 and 8580 are exactly the same chips if I'm not mistaking.

[TK.]

Yes, version number isn't incremented this time

By the way: What is the difference between setup_mb8580 and setup_mb6582? The 6582 and 8580 are exactly the same chips if I'm not mistaking.

Some precompiled setups are part of this package:
   o setup_6581.hex            (MBSID stuffed with 6581)
   o setup_8580.hex            (MBSID stuffed with 8580)
   o setup_tk.hex              (TK's Setup)
   o setup_mb6582.hex          (MB-6582 Setup)[/code]
To check the difference, type:
diff setup_8580.asm setup_mb6582.asm
Best Regards, Thorsten.

[renepela]

Thanks Thorsten. It seems the differences are in the LCD display (4 lines instead of 2) and the shiftregisters.

How can I compile myself to increment the version number? I found the version numer is in main.inc so all I have to do is change it there and then recompile.

Or is there perhaps a way to change it directly in the hex file with a hex editor?

Best regards,

Rene

[TK.]

Or is there perhaps a way to change it directly in the hex file with a hex editor?

If you find the location and calculate a new checksum for the appr. line, it could work - but it's error prone.

For details, how to build a new .hex file, see

  http://www.midibox.org/dokuwiki/application_development

However, I re-uploaded the .zip package with changed version number.

Best Regards, Thorsten.

[renepela]

Thanks Thorsten.

[nILS]

Found some oddness:

* While playing around with the SID I noticed that it seems to be impossible to set the ARP direction via sysex (according to the sysex implementation sheet the editor is doing it right, it just doesn't have any effect). I asked Wilba to try to reproduce this and he had the same issue.

* Rutger's editor shows some arp directions that are not documented in the sysex implementation docu.

[TK.]

* While playing around with the SID I noticed that it seems to be impossible to set the ARP direction via sysex (according to the sysex implementation sheet the editor is doing it right, it just doesn't have any effect). I asked Wilba to try to reproduce this and he had the same issue.

Works at my side with the latest editor release, and the improved version which is already in the repository.

Maybe you tried to change the direction of an oscillator which isn't enabled? (check the waveform settings)

It could also make sense to activate the oscillator link at the bottom of the editor.

Rutger's editor shows some arp directions that are not documented in the sysex implementation docu.

fixed in the docs

Best Regards, Thorsten.