Help With MBSID customisation

[Jaicen]

Ok, I made a post about customising the MBSID control surface in the SID part of the forum, but I now realise that it would probably be better off here. I'm trying to modify the code for the control surface to create a less comprehensive control surface using just one DINx4 and 2 DOUT shift registers.

The idea is that I can mount all the components including buttons and encoders on a PCB with the shift registers, drastically reducing the amount of wiring that's needed.

Now, what I need to know is how to assign the pins of the DIN to specific functions, for example I'd like SR 1 P 0 to assign VCF to OSC1 of the currently selected SID. I've looked at the code for the encoders table, but it doesn't make a whole heap of sense to me just yet.

I'm not wanting someone to do this for me, I want to learn how the code works so I can do it myself. Stryd has been very helpful so far but I still need some handholding to find the info which i'm sure i here.

Can anybody help?

Oh I should mention that all the code I find and any layouts I create will be posted to the WIKI for public use.

[TK.]

MBSID is not a C application, therefore I've moved the article to the right section.

In general you can get some useful tips in these articles, because there are users who did customizations before.

Although these are no specific examples for your purposes, I think that they should give you enough input to understand, where changes have to be made...

It would be great, if you could write a summary in the Wiki, because this is a frequently asked question, I spent the effort to explain this in the past, but I'm tired to do this again and again...

http://www.midibox.org/forum/index.php?topic=6387.0

http://www.midibox.org/forum/index.php?topic=5039.0

http://www.midibox.org/forum/index.php?topic=5020.0

http://www.midibox.org/forum/index.php?topic=3655.0

http://www.midibox.org/forum/index.php?topic=5261.0

http://www.midibox.org/forum/index.php?topic=4198.0

http://www.midibox.org/forum/index.php?topic=4948.0

http://www.midibox.org/forum/index.php?topic=6674.0

http://www.midibox.org/forum/index.php?topic=7084.0

http://www.midibox.org/forum/index.php?topic=3925.0

http://www.midibox.org/forum/index.php?topic=6252.0

http://www.midibox.org/forum/index.php?topic=3642.0

http://www.midibox.org/forum/index.php?topic=1212.0

Best Regards, Thorsten.

[Jaicen]

Thanks for that TK, looks like i've got plenty of reading to get done.

I'm quite happy to document everything, i'm sure it's frustrating explaining things over and over to people who then either do nothing or disappear altogether.

If I'm successful, i'll write a step by step tutorial explaining exactly how to modify the code for each 'module' (ie, the VCF section, the VCA etc).  That way it's all broken down into easily digested chunks.

[Jaicen]

Ok, I think i'm getting somewhere now! I've had a quick scan (not in depth, i'm off out now) of a few of the articles, and it seems that most of the functions are already coded, so i'll start by using them rather than having to re-invent the wheel. Although the buttons don't do exactly what I wanted, I guess it's not a big deal, for example, if I want to assign more than one filter type, I can use the dedicated button  which will bring up the other types on the LCD menu, and I can choose another from there.

Right, so this is the code for all the buttons I want which i've just copied and pasted from cs_menu_io. Pin's are not assigned yet as I don't have time but is this all I need?

S_MENU_DIN_TABLE

;; Function name SR# Pin#

DIN_ENTRY CS_MENU_BUTTON_Dec, 1, 0 ; only valid if rotary encoder not assigned to these pins

DIN_ENTRY CS_MENU_BUTTON_Inc, 1, 1 ; (see mios_tables.inc) and CS_MENU_USE_INCDEC_BUTTONS == 1

DIN_ENTRY CS_MENU_BUTTON_Exec, 1, 2

DIN_ENTRY CS_MENU_BUTTON_Sel1, 1, 7

DIN_ENTRY CS_MENU_BUTTON_Sel2, 1, 6

DIN_ENTRY CS_MENU_BUTTON_Sel3, 1, 5

DIN_ENTRY CS_MENU_BUTTON_Sel4, 1, 4

DIN_ENTRY CS_MENU_BUTTON_Sel5, 1, 3

DIN_ENTRY CS_MENU_BUTTON_SID1, 2,          0

DIN_ENTRY CS_MENU_BUTTON_SID2, 2,          1

DIN_ENTRY CS_MENU_BUTTON_Link, 2, 4

DIN_ENTRY CS_MENU_BUTTON_Osc_Sel, 4, 2

DIN_ENTRY CS_MENU_BUTTON_Osc_Wav,  4, 4

DIN_ENTRY CS_MENU_BUTTON_Env_Sel, 7, 2

DIN_ENTRY CS_MENU_BUTTON_Fil_Sel, 7, 4

DIN_ENTRY CS_MENU_BUTTON_Fil_Mod,  0, 0

DIN_ENTRY_EOT

So for example, SID1 & SID2 will select the SIDS individually, and pushing LINK will allow me to edit them both at the same time? Is that right? I want to be able to push buttons for OSC1-3, which will apply any changes made to the OSC's selected, is this how the OSC button works?

If i'm correctly interpreting this, the code here will allow me direct access to: both envelopes (but not at the same time which i'd like), OSC1-3 and waveform, filter on/off and type (HP/BP/LP) and Both SIDs.

[TK.]

Pin's are not assigned yet as I don't have time but is this all I need?

you will see it when you are trying it out on your MBSID. Since software can be changed and uploaded very fast, I think that there is no real need to doublecheck this (I don't know this part of the firmware so well anymore, it's three years ago where I programmed this...)

So for example, SID1 & SID2 will select the SIDS individually, and pushing LINK will allow me to edit them both at the same time? Is that right?

no, when you hold SID1, and press SID2 at the same time, you will select both and can edit both.

The link button just only opens the MIDI gate to the slave SIDs (disabled by default to avoid feedback loops with your sequencer software, if MIDI loopback is enabled there as well)

I want to be able to push buttons for OSC1-3, which will apply any changes made to the OSC's selected, is this how the OSC button works?

Yes, changes will be made to all selected OSCs and all selected SIDs.

E.g., if you select all 4 SIDs, and all 3 OSCs, and change the portamento parameter, you will do this change on all 12 oscillators at the same time.

This is a very important feature for polyphonic sounds, therefore I implemented this

If i'm correctly interpreting this, the code here will allow me direct access to: both envelopes (but not at the same time which i'd like)

yes, modifying two ENVs at the same time hasn't been implemented

For the LFOs it is not possible as well. Maybe I can add this possibility into MBSID V2 (such changes have to be done considered at the beginning, it's too difficult to do this later)

Best Regards, Thorsten.

[TK.]

Here short 200k video about the SID buttons which (hopefully) says more than 1000 words... ;-)

http://www.midibox.org/videos/mbsid_cs_sidbuttons.avi

Best Regards, Thorsten.

[Jaicen]

TK, you're a genius! That video really does make things much clearer. I think it would be brilliant to have a short video in the WIKI that shows you programming a patch from scratch. That would help enormously in understanding how all the buttons work and interact.

For instance, If I have SID1 OSC1 selected, and I then push the BP button, will that assign the filter to that voice, or do I need to have assign buttons for it? 

With regards to modifying the two Env's, that's not too big a deal as long as the ADSR and DEPTH encoders can be switched between them. I think it would be nice to modify multiple LFO's, but wouldn't that be effectively the same as making 1 LFO modulate two destinations??

edit: The ninth post you've put up there was my original post in the SID forum ;)

[Jaicen]

OK, I think i've found the code I need to assign the encoders on my CS. I think it's something along these lines, unless i've missed something.

;; Filter section

;; Function name parameter   menu offset cursor pos

CSENC_ENTRY CS_MENU_ENC_CHANGE_SYS, CS_SID_FILTER_CUTOFF,   CS_MENU_FIL, 0x00, 0x00

CSENC_ENTRY CS_MENU_ENC_CHANGE_SYS, CS_SID_FILTER_RESONANCE,  CS_MENU_FIL, 0x00, 0x01

If i'm interpreting this correct, this will assign VCF cutoff to an encoder on the first two pins of shift register 1, and Resonance to the third and fourth pins of shift register 1.

The remaining encoders are as follows (if i'm right), but here I haven't altered the SR allocations, they're the same as the standard CS.

;; OSC "Misc" Layer

;; Function name parameter   menu offset cursor pos

CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_FINETUNE,   CS_MENU_OSC, 0x09, 0x0a

CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_PORTAMENTO, CS_MENU_OSC, 0x09, 0x0b

#endif

CS_MENU_ENC_TABLE

;; OSC "Env" Layer

;; Function name parameter   menu offset cursor pos

CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_DELAY,   CS_MENU_OSC, 0x03, 0x03

CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_ATTACK,   CS_MENU_OSC, 0x03, 0x04

CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_DECAY,   CS_MENU_OSC, 0x03, 0x05

CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_SUSTAIN,   CS_MENU_OSC, 0x03, 0x06

#else

CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_RELEASE,   CS_MENU_OSC, 0x03, 0x07

#endif

The reason I wanted this looked over is so that I can be sure i'll be able to get my CS running before I build it. I didn't want to build something I couldn't use, but i'm fairly confident tha this will work now. If I assign these 9 encoders and however many buttons to the first 32 pins on a DINX4, I don't need to modify the rest of the code, unless it's causing a conflict is that right? ie, if an encoder is assigned to a DIN Pin that doesn't exist, I don't need to take it out of the code do I?

If this is pretty much all that I need to do, I can start drawing up a layout for my CS PCB which hopefully will incorporate shift registers for DIN and DOUT. There should be very little wiring involved in my SID (I HATE wiring things up!).

[TK.]

I don't need to modify the rest of the code, unless it's causing a conflict is that right?

if there is no commented or undocumented restriction: yes (it should, but who can guarantee this without testing... ;-))

ie, if an encoder is assigned to a DIN Pin that doesn't exist, I don't need to take it out of the code do I?

yes, this shouldn't affect the behaviour.

Here a video of a short SID session. It's far from a perfect live performance, especially because there was this tripod of my digicam before my face, I wasn't able to handle the interface like I'm normaly doing... :-/

-> http://www.midibox.org/videos/mbsid_bassline_session.avi (15 MB)

Best Regards, Thorsten.

[Wilba]

Thanks for that first video, TK... I've been so curious about how the metering of LFO/Env looks, now I know  :)

[Jaicen]

TK, that's damn cool you should try and get that hosted in the WIKI or something.

One thing that's puzzling me is how you turned on the two types of filter at the end, how is that achieved with just one button??  That'll save me a couple of pins if it's not just my imagination!

[Jaicen]

I think that i've got all the parameters that I need for this control surface. I've tried to fit everything onto a single DINX4 for compatibility, for instance if someone wants to use the code without one of the PCB's i'm going to design. I can't find the code for applying an encoder in place of the inc/dec buttons but i'm sure it's about somewhere.

Are these all the changes that I need to make to use my custom control surface? I haven't had time to work on the DOUT yet, but I should have that done by next week.

S_MENU_DIN_TABLE

;; Function name SR# Pin#

DIN_ENTRY CS_MENU_BUTTON_Dec, 1, 0 ; only valid if rotary encoder not assigned to these pins

DIN_ENTRY CS_MENU_BUTTON_Inc, 1, 1 ; (see mios_tables.inc) and CS_MENU_USE_INCDEC_BUTTONS == 1

DIN_ENTRY CS_MENU_BUTTON_Exec, 1, 2

DIN_ENTRY CS_MENU_BUTTON_Sel1, 1, 3

DIN_ENTRY CS_MENU_BUTTON_Sel2, 1, 4

DIN_ENTRY CS_MENU_BUTTON_Sel3, 1, 5

DIN_ENTRY CS_MENU_BUTTON_Sel4, 1, 6

DIN_ENTRY CS_MENU_BUTTON_Sel5, 1, 7

DIN_ENTRY CS_MENU_BUTTON_SID1, 2,          0

DIN_ENTRY CS_MENU_BUTTON_SID2, 2,          1

DIN_ENTRY CS_MENU_BUTTON_Osc_Sel, 2, 2

DIN_ENTRY CS_MENU_BUTTON_Osc_Wav,  2, 3

DIN_ENTRY CS_MENU_BUTTON_Env_Sel, 2, 4

DIN_ENTRY CS_MENU_BUTTON_Fil_Sel, 2, 5

DIN_ENTRY CS_MENU_BUTTON_Fil_Mod,  2, 6

DIN_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_FINETUNE,  2,    7

DIN_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_PORTAMENTO,  3,  0

DIN_ENTRY CS_MENU_ENC_CHANGE_SYS, CS_SID_FILTER_CUTOFF,   3,  2

DIN_ENTRY CS_MENU_ENC_CHANGE_SYS, CS_SID_FILTER_RESONANCE,  3,  4

DIN_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_DELAY,   3,  6

DIN_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_ATTACK,   4,  0

DIN_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_DECAY,   4,  2

DIN_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_SUSTAIN,   4,  4

DIN_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_RELEASE,   4,  6

DIN_ENTRY_EOT

[TK.]

One thing that's puzzling me is how you turned on the two types of filter at the end, how is that achieved with just one button??

The button cycles through following filter type combinations:

        dw      "L-- "

        dw      "-B- "

        dw      "LB- "

        dw      "--H "

        dw      "L-H "

        dw      "-BH "

        dw      "LBH "

Best Regards, Thorsten.

[Jaicen]

Ah, brilliant! Can I assume that the OSC select button works in a similar way??

The one thing I haven't been able to find, is what the particular functions are actually doing. I understand that encoders are allocated by designating a 'function' such as CS_SID_VOICEx_FINETUNE.

What this 'function' does is defined by another table, but I don't really understand how that code is applied to alter the parameter of fine tune. It would be nice to have some hints as to what the program is doing, so that we can better understand how to change that behaviour. As I said before, I don't want to re-invent the wheel if at all possible, but I would like to understand why it rolls ;)

[TK.]

For the oscillator button, this behaviour has to be explicitely activated. I use the "faster handling" (one 1--, -2-, -3-) instead, and when I want to change multiple OSCs at the same time, I just click on the appr. "general purpose" button in the menu section (which shows the OSC selection as well), and change the desired combination there.

This behaviour can be changed in main.asm:

        ;; if 0: OSC button selects also combined modes (7 states, combined OSCs)
        ;; if 1: OSC button selects only one of three OSCs (faster handling)
#define CS_MENU_OSC_BUTTON_BEHAVIOUR 1
[/code]
What this 'function' does is defined by another table, but I don't really understand how that code is applied to alter the parameter of fine tune. It would be nice to have some hints as to what the program is doing, so that we can better understand how to change that behaviour. As I said before, I don't want to re-invent the wheel if at all possible, but I would like to understand why it rolls
I hope it's acceptable from your side, when I cannot help that much here. I've already a very reduced sparetime to continue with my MIDIbox projects, and each moment I find some time, I've to decide "should I reply some emails", "should I help some people in the forum", "should I continue with any documention", or just "can I continue with programming something new?" - what would you prefer?
It has also to be considered, that writing a really understandable documentation takes 2..4 times longer than just hacking the code.
I really know, that for some people it's difficult to understand the whole programming concept since many parts are scattered over different .inc files - on the other side, this is the only possibility for myself to reach such a complexity and variability.
So, I think that your question was just because you didn't thought about how much effort a sufficient answer produces at my side. Therefore I give you just the hint: open the main.lst file, which contains the whole assembled code and search for some keywords there (this file is only available when you've started the assembler by yourself, it is deleted on release packages).
And if you want to help the community by yourself, document your findings in the Wiki.
Another point I want to highlight: writing a complete documentation means for me, that I have to take care that I don't change conceptional thinks too much anymore, because this would either require to write a second documentation about the new implementation, or that the old one is expired, and no new one is available (-> wasted effort)
I see this as a inhibition threshold for implementing anything new. E.g. the CS handler like it is currently implemented in MBSID was very different in older releases, I changed most of the functions in order to make it faster, and to reduce the memory consumption.
I'm planning a redesign again for MBSID V2
And this is by the way the next point: what happens, if I decide to make a certain button or LED of the control surface more important than it currently is? Do I need to take care for all the variations which could be created in future by different people (variations, which I could never try out by myself), or do I have the freedom to change like I (and most other users) find it optimal?
Just my thoughts... hope that this also makes it more understandable, why - in the meantime (it was different 4 or 5 years ago), I really cannot give detailed answers on any questions, regardless if they are interesting for multiple people, or only for a single guy...
At the end I think, that the community has to push the documentation forward without much help from my side. Everything else is additional effort at my side for a small number of people. It prevents me to continue with new stuff which makes myself and many other people happy.
Best Regards, Thorsten.

[Jaicen]

Thanks for the hints TK, I think i'm getting towards being able to finalise my design criteria for the PCB. I was expecting some others to chime in here but it looks like we're alone in this ;)

I fully understand that your time is limited. Obviously this is a large community, so you can't give one on one guidance to everyone.

Since this is supposed to be an open source user configurable project, I just have a few comments which are not intended as criticism or in any way negative, merely my views specifically relating to the MBSID project.

So far, i've not been able to find more than three or four MBSID's which have been created with any modifications at all. I suspect this is because the way in which the hardware platform has been created means that while it is hugely flexible and re-configurable for those in the know (ie, TK!), those that are on the outside of the project looking in find it very difficult to understand. I'm not saying that there should be a complete documentation, just more hints! For example, whilst re-designing for V2, whenever you add a piece of code like CS_SID_VOICEx_FINETUNE, put a little comment in saying what it does. I know there are a few already, but not really enough to be able to work out how to do something differently.

I don't think you need to be taking into account the modifications made to your work by anybody but yourself. Your designs are already hugely flexible, if only we knew how!

[TK.]

You can be sure, that I don't understand this as critism! :)

But I know, that it isn't done with putting just an additional comment to a line of code

(how big is your screen?), it is still useless for people who don't know the whole programming

concept, who don't know how to read assembly code, and which programming rules I'm using in my code.

Let's go back to the CS_SID_VOICEx_FINETUNE example: as you can see in this line:

	;;		Function name		parameter		  menu		offset	cursor pos
	CSENC_ENTRY	CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_FINETUNE,	  CS_MENU_OSC,	0x09,	0x0a
[/code]

(do you see, how many comments I would already have to add to this single line?)

it's a parameter number. And these numbers are defined in app_defines.h - where you can find the
hint:
[code]
	;; offsets to registers (we are using the same like for the presets (sid_presets.inc),
	;; so that SID_SYSEX_TABLE can be reused

so, you are addressing registers with these parameter numbers, registers which hold the sound parameters. The same parameters are also part of a patch, and which are stored in a SysEx structure. For a newbie this might lead to following questions:   - what is a parameter?   - what is the difference between a register and a parameter?   - what is a SysEx structure   - what is finetune?   - what does the VOICEx mean here?   - what is a voice?   - what is the difference between a voice and an oscillator, if any?   - and what the heck is the purpose of all the other constants and function names in this single line:

	;;		Function name		parameter		  menu		offset	cursor pos
	CSENC_ENTRY	CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_FINETUNE,	  CS_MENU_OSC,	0x09,	0x0a
[/code]
So, hope you see the desaster. "adding some more comments" is no real solution.
I think that it would more help, if somebody would describe in his own words, how he did the
modifications, where he found the informations, etc...
It could also be required to describe, how a synthesizer is working, what for example
"finetune" means...?
Finding out all the details might take some weeks, regardless if I'm giving even more hints or not.
There is definitely no 1-2-3 way for CS modifications, and I hope that - in distance to others -
you are writing down all your findings in the Wiki
MIOS is a text adventure...
Best Regards, Thorsten.

[stryd_one]

Heya Jaicen. If you really want to kinow how it all works, there's one sure-fire way to go. Get the PIC datasheet, be online ready to google stuff you don't know about, open up main.asm, and start reading :) Just follow the code, as if you were the PIC executing it... When you see something written which you don't understand, often if you use a text search over all the source files of the project, you will find other mentions of that thing in other files, with some hints as to what it does. It will take a very long time before you've read all the code for the whole app, but trust me, unless you're TK, there's no way to get to know the apps better :)

[Jaicen]

I dig it!

You're probably right about the comments, that's just an idea I had for user friendliness inspired by an old book of commodore BASIC programs I have.

I do plan to go over and over the code until it hopefully starts to make sense. I'm away from my PC at the minute, but as soon as I get back i'm going to look over main.asm, hopefully that will make things a little clearer.

I've pretty much decided not to go overboard with this project, i'll just re-use the features you've already implemented in your control surface, but in a less comprehensive fashion. In this way, i'll hopefully be able to show how the control surface can be configured from the step A (LCD + 5 buttons) through a 10 button LCD, to a minimal control surface (as already defined at the start of the thread. Because i'm re-using all the standard CS code, it would be possible, having built the minimal CS to add  further DINx4/DOUT modules for more encoders/buttons until you reach the full CS. Does that all make sense?

As I said before, i'm going to design a PCB to contain all my shift registers for both the DIN and DOUT's to save on wiring. I'll release this to the WIKI too, but it will be compatible with Smash's DINX4 modules so others can re-use my work to customise their own designs. I'd really like to see more people customising their SID's, that's what it's all about for me (that and the sound!).

[TK.]

that's just an idea I had for user friendliness inspired by an old book of commodore BASIC programs I have.

An impressing assembly code in respect of the comments is Jarek's AVR Synth (-> http://www.jarek.synth.net/AVRSYN.asm) - note especially the aesthetic ASCII art ;-)

However, not everbody has the talent to document his code in an understandable way...

In this way, i'll hopefully be able to show how the control surface can be configured from the step A (LCD + 5 buttons) through a 10 button LCD, to a minimal control surface (as already defined at the start of the thread. Because i'm re-using all the standard CS code, it would be possible, having built the minimal CS to add  further DINx4/DOUT modules for more encoders/buttons until you reach the full CS. Does that all make sense?

Yes!!! Especially the button reconfiguration for the 2x40 LCD options is a FAQ, it would be great if a step-by-step guide would be available

Best Regards, Thorsten.

[stryd_one]

TK I think your code has some of the best commenting that I've ever seen. You do just fine :)