Programming functions into the MIOS

MIOS programming (Assembler)
1

I’ve been away from these projects for a while because i was finishing up school. Now that that’s finished i finally got some time again for my own midicontroller. I got back onto ucapps.de and saw that there was a new concept called MIOS. Looks very good and i have some questions about it that i can’t find in the infos and stuff like that. Maybe i overlooked them…

I want to build a midicontroller for my DB50XG ‘external conversion’. The DB50XG is a daughterboard synthesizer that connects to a ‘waveblaster port’ on the old Creative Labs soundcards and some other old ISA cards. I found 2 conversion to make it external, but both of them aren’t quite good enough as there isn’t a control interface in eiter of them.

If anyone could help me out? The MIOS looks like a very nice interface for my synth, but i want to know the following:

1   What kind of things have to be programmed by me and what kind of functions are already in the software? I don’t understand the functions section in the MIOS info section, because it’s all written in ‘assembler code’?

2   A lot of functions in the synth have to be controlled by sysex. Can i program MIOS to send a specific sysex message to the synth when i push a specific button on the midicontroller? Can this button be an analog trigger or does it have to be a ‘digital’ button trigger?

3   It used to be possible to send Thorsten the PIC to burn a certain firmware into the PIC. Is it still possible and is this service also available for burning the Bootstrap Loader into the new PIC?

4   In the manual of the DB50XG it says that some functions can be controlled directly by external controllers. Does this mean i only have to use the control numbers (or CC’s?) to assign the function to a pot/fader or button? I don’t have to use sysex for these functions, right?

5   In the design for the old MidiboxPlus there were buttons for going up and down in the banks. Are these buttons still available in the MIOS or do i have to program these funtions into the MIOS?

6   In the old MidiboxPlus project it was possible to switch between bautrates and therefor it was possible to build both the ‘normal midi i/o interface’ and the ‘Midi-to-COM Rs-232 interface’ into the same box. If i understand correctly, this isn’t possible in the new MIOS concept, right?

7  If i need to program the MIOS myself to get some functions to interact with certain buttons or pots/faders (above questions), do i need to learn that assembler language or are there easier alternatives? What kind of software would i need? I’m working on a wintendo system and i think most of you DIY people and developers work on a Linux system, right?

Well, i’ll stop here before it gets to long.

I hope some of my questions can be resolved.

Very nice by the way that it’s possible to get some free PIC samples on the Microchip site. I got 3 of the new PIC type that Thorsten introduced for the MIOS concept. Very nice, i like free stuff.

2

Sounds interesting :slight_smile: I’m sure it would be possible to whip up some code to do this

What does the DB50XG do that the SID can’t?

3

I don’t know what the DB50XG can do what the SID can’t.

All i know is that it just sounds different because the DB50XG uses FM synthesis and i have it laying around here. I just thought it would be nice to make it as an external synthesizer instead of using that crapass pc everytime i want to use it. And i have to use an old ISA souncard to get it to work.

And i’m also planning on building the SID, but i’m gonna wait until i’ve finished the DB50XG conversion and until the control interface + according software for the SID has been made available.

4

Hi Nomical,

don’t mix MIOS with the MIOS application. MIOS gives you all the basics for implementing an application, and it doesn’t have to be changed, you can use the same operating system like all other applications.

What kind of things have to be programmed by me and what kind of functions are already in the software? I don’t understand the functions section in the MIOS info section, because it’s all written in ‘assembler code’?

You have to program the whole user interface. Currently it can only be programmed in the assembler language, support for higher level languages is not planned for this year (as there are no suitable freeware compilers available yet).

A lot of functions in the synth have to be controlled by sysex. Can i program MIOS to send a specific sysex message to the synth when i push a specific button on the midicontroller? Can this button be an analog trigger or does it have to be a ‘digital’ button trigger?

See the MIDIbox SID application how SysEx data can be send (yes, I know, it’s very complex, but this is just the result when you want to create a perfect interface). In fact you can send and receive any MIDI data, but you have to call “MIOS_MIDI_TxBufferPut” for every single byte, there is no routine like “MIOS_MIDI_TxBuffer_SysExPut” or whatever since such a function has to be writting in the application layer (see SID application, cs_menu.inc, after CS_MENU_SendParameter_Slave as an example)

It used to be possible to send Thorsten the PIC to burn a certain firmware into the PIC. Is it still possible and is this service also available for burning the Bootstrap Loader into the new PIC?

sure :slight_smile: I only have to burn the bootstrap loader into the PIC, thereafter you are able to burn MIOS and the application via the MIDI line as much times as you want.

In the manual of the DB50XG it says that some functions can be controlled directly by external controllers. Does this mean i only have to use the control numbers (or CC’s?) to assign the function to a pot/fader or button? I don’t have to use sysex for these functions, right?

yes, some functions can be controlled by CC’s, but the DB50XG supports much more parameters. So if you want to control the whole parameter set, you have to go for SysEx. However, for the application this doesn’t make a big difference.

In the design for the old MidiboxPlus there were buttons for going up and down in the banks. Are these buttons still available in the MIOS or do i have to program these funtions into the MIOS?

you have to program these functions into your application. There are driver hooks like USER_DIN_NotifyToggle which allow you to react on button movements

In the old MidiboxPlus project it was possible to switch between bautrates and therefor it was possible to build both the ‘normal midi i/o interface’ and the ‘Midi-to-COM Rs-232 interface’ into the same box. If i understand correctly, this isn’t possible in the new MIOS concept, right?

This is still possible by calling the MIOS_MIDI_InterfaceSet function. And you are also able to specify the default interface (RS232 or MIDI) in the ID field of the PIC, so that the correct setting is already available at power-on

If i need to program the MIOS myself to get some functions to interact with certain buttons or pots/faders (above questions), do i need to learn that assembler language or are there easier alternatives? What kind of software would i need? I’m working on a wintendo system and i think most of you DIY people and developers work on a Linux system, right?

see the descriptions in the main.asm file of any applications which tools are required for Wintendo. However, as I wrote: currently only assembler is supported.

Some more words: maybe the planned port of MIDIbox64 to MIOS will help you much more, because it will also be a good skeleton for customized controllers for those who feel that the SID application is too complex. But I will not start with this task before the running projects have been finished (maybe in 2-3 months…)

Best Regards, Thorsten.

5

Btw.: here the code to send a SysEx string to a DB50XG

Send_SysEx_DB50XG
        ;; MIDI channel in MIOS_PARAMETER1
        ;; parameter number in MIOS_PARAMETER2           
        ;; parameter value in MIOS_PARAMETER3 
        movlw   0xf0
        call    MIOS_MIDI_TxBufferPut
        movlw   0x43
        call    MIOS_MIDI_TxBufferPut
        movlw   0x10
        call    MIOS_MIDI_TxBufferPut
        movlw   0x4c
        call    MIOS_MIDI_TxBufferPut
        movlw   0x08
        call    MIOS_MIDI_TxBufferPut
        movf    MIOS_PARAMETER1, W      ; send channel
        call    MIOS_MIDI_TxBufferPut
        movf    MIOS_PARAMETER2, W      ; send parameter number
        call    MIOS_MIDI_TxBufferPut
        movf    MIOS_PARAMETER3, W      ; send parameter value
        call    MIOS_MIDI_TxBufferPut
        movlw   0xf7
        call    MIOS_MIDI_TxBufferPut
        return

this function can be used from any hook, this means: you can trigger this SysEx string in your application with buttons, pots, faders, rotary encoders, etc without writing special drivers for these control elements, because the drivers itself are provided by MIOS.

Best Regards, Thorsten.

6

So if i understand correctly,

1   Every command/function i want to control inside my DB50XG has to be programmed/assigned to the button or pot/fader i want to use on the controller?

2   For the more complicated funtions i have to write/implement sysex messages (those messages are described in the manual of my DB50XG, is it not?) into an application that i have to load into the MIOS, right?

3   The easier functions that can be controlled directly with CC’s/external controllers, do not have to be implemented into an separate application that has to be loaded into the Mios, but instead they can be ‘learned’ by the controller because there already is an application for MIOS that controls the use of CC’s/external controllers, right?

Thortsen:

Quote:In the manual of the DB50XG it says that some functions can be controlled directly by external controllers. Does this mean i only have to use the control numbers (or CC’s?) to assign the function to a pot/fader or button? I don’t have to use sysex for these functions, right?  

yes, some functions can be controlled by CC’s, but the DB50XG supports much more parameters. So if you want to control the whole parameter set, you have to go for SysEx. However, for the application this doesn’t make a big difference.

What do you mean with ‘However, for the application this doesn’t make a big difference’?

Oh Thorsten, it seems as if you have more knowledge of the DB50XG and it’s external conversion. Do you perhaps have some extra info for me or do you know where to find more info. The only stuff i’ve found is in French which i can’t understand or it’s from Elektor which isn’t satisfying for me.

Thanks

7

You are fast Thorsten!

Before i’ve written an reply to you, there’s already a new one by you.

Thanks for the fast replies and i’ll try to keep up.

8

Hi Thorsten,

I looked at the bit of code you posted above and i have question about it.

At only has 3 variables i can change, right? Thirst the midi channel, second the parameter number and third the parameter value.

So, do i only need to write different versions of this code for every function i want to control? And can these versions be put in one file (the above file) or do these have to be seperate files that i have to load into the MIOS myself?

How does the trigger part work? I ‘call’ upon that specific string (the one above or the ones i have to write myself)? How do i do that?

Sorry for these questions, but it’s getting clearer by the minute. I can learn pretty fast, but i haven’t got the feel for this programming stuff yet. Yet…

9

Hi Nomical,

no, you don’t need to copy this function, the parameters are used like variables, they have to be initialized before Send_SysEx_DB50XG will be called. There are different possibilities to initialize the parameters, normaly you only need to specifiy the “XG parameter number”, which could be stored in a table. The parameter value is given by the pot/encoder/button position, and for the MIDI channel you could use a global register (=variable) which could be incremented/decremented by two special buttons or by an encoder

For more details I don’t want to repeat what I already wrote in the examples. Please take a look into the MIOS download section, there are several .zip files which include documented code. The comments describe exactly how to react on buttons, pots, encoders, etc.

Once you’ve read these examples, you are possibly on a level where I can describe you the tricks in one sentence. If the examples are too difficult to understand, I will possibly not be able to describe it better anyhow. :-/

Best Regards, Thorsten.

10

By the way:

The only stuff i’ve found is in French which i can’t understand or it’s from Elektor which isn’t satisfying for me.

The Elektor project which controls the XG was a publication by me  ;-)

This was the very first MIDIbox, very reduced and very expensive (it came with an external AD converter)

Do you just only want to control XG parameters, or do you plan to write a complete control surface like the MIDIbox SID CS?

Best Regards, Thorsten.

11

That’s funny, you’re the man behind that conversion. How small can this world be.

Well, i took a look at the manual of the DB50XG and there are A LOT of functions to control. Far too many for the interface i was initially thinking about.

So i’m thinking of something different. Could MIOS be used to make a interface that uses a menu to control certain functions? This would probably require a second and bigger display, right? Would it be possible to make a menu which has a couple of buttons and pots that control the function that’s currently assigned/displayed?

I guess that would take a lot of effort, making such a menu, or would it not?

The idea is to have control over as many parameters in the synth as possible, except for the sequencing stuff which will be handeled by a different machine.

It would indeed become more like the Midibox SID CS.

I’ve already worked on a redesign of you’re Elektor DB50XG conversion. The main idea was to get rid of the ‘opamp’ audio section on the card and replace it with a normal ‘Line out’ section that can even mix the L + R signals together if only one of the two plugs is inserted in the main audio outs.

12

Hi Nomical,

ok, it seems that we are talking about a different Elektor project. I’ve created a MIDI controller for a XG some years ago which have been published in Elektor 2/2000. But this was a really simple implementation which only allowed to access the most important parameters. Of course, I also used my XG50 standalone :slight_smile:

If you want to control all the available parameters a much more complex user interface is required. I’m very sure that this can be realized with MIOS, bigger displays and a complex menu structure are no problem (you could also use a graphical LCD), but note that the implementation requires some PIC programming skills and a lot of time. I cannot provide a 1-2-3 solution for you, I can only say that MIOS simplifies the implementation and I can refer to the existing applications. Everything else is in your hand.

Best Regards, Thorsten.

13

Ok, I’ve begun to read the files from the MIOS d/l page and i’m beginning to see some structure in it. I’ve also d/l all the software that’s needed for writing the code and all. Haven’t installed it yet, so i don’t understand what activeperl is for.

Anyway, I looked at your SID control surface and i see something that resembles the Yamaha A3000 interface. Is it so that the rotary encoders beneath the display control the functions that are currently displayed exactly above the encoders on the LCD? If so, i could use this as a skeleton for my own control interface, right? I’m thinking about making it in such a way, is this still possible if i can’t use your SID CS as a skeleton?

Oh, and the rotary encoders on the A3000 can also be used as (digital?) pushbuttons. Is something like that easily integrated into MIOS? Would be very cool…

All the CC messages and sysex messages that i want to use, will have to be put in MIOS_TABLES.inc, right? I looked at the snippet you posted above for sending sysex to the DB50XG, but i don’t understand something. Why is it that the number of lines in your sysex message as less than what it says in the DB50XG manual? In other words, You only input the midi channel, parameter number and the parameter value. In the manual it says that you also have to send the following sysex messages if you want to change the variation effect type to for instance Echo:

11110000 F0 Exclusive status

01000011 43 Yamaha ID

0001nnnn 1n Device Number

01001100 4C XG Model ID

00000010 02 Address High

00000001 01 Address Mid

01000000 40 Address Low

00000111 07 Data (Variation Type MSB)

00000000 00 Data (Variation Type LSB)

11110111 F7 End of exclusive

So my question is, why are there less strings/messages/whatever in your snippet for sending sysex to the DB50XG? And if i have to do it like i described from the manual, can i put all of these ‘blocks of messages’ into MIOS_TABLES.inc?

Display question. It’s possible to display for example the actual delay time in ms instead of the decimal/heximal value on the lcd that you have to input in the sysex message, right? If so, do these tables with conversion values to ms (there are about 9 of them) have to put into MIOS_TABLES.inc or do they have to be somewhere else?

How much space is there in the MIOS to build a menu for the LCD? You also got an DB50XG Thorsten ( that’s what i’ve understood!), so you know how big the menu could be. I want almost every parameter to be accessed from the menu if possible. The menu should also diplay all correct values and names of effects, parameters and values. Some encoders have to control functions that are diplayed above them on the display as yoy go through the menu, other pots, encoders and buttons should control fixed functions. Would there be enough space in the PIC to implement all of this?

One thing i don’t understand about the bankstick. Is it possible to implement a code into the MIOS that allows two buttons to directly load and save a setup into the bankstick? Or have i overlooked it and is this code already present in MIOS? Isn’t there any space in the PIC for saving user setups? Or will this space only be used to implemnt future functions?

And how is midi feedback handeled by the hardware or MIOS?

Do you know of any sites or ebooks that have some really good info for starting PIC programmers? When i search with google i get so many sites, i don’t know which ones are any good!

Thanks.

14

> Ok, I’ve begun to read the files from the MIOS d/l page

> and i’m beginning to see some structure in it. I’ve also

> d/l all the software that’s needed for writing the code

> and all. Haven’t installed it yet, so i don’t understand

> what activeperl is for.

without perl you are not able to convert the assembler code

to a SysEx (.syx) file, which thereafter has to be uploaded

to the core module by using MIDI-Ox

> Anyway, I looked at your SID control surface and i see

> something that resembles the Yamaha A3000 interface. Is

> it so that the rotary encoders beneath the display control

> the functions that are currently displayed exactly above the

> encoders on the LCD?

This is planned for Step-C of the control surface. Currently

the handling is different, see the Step-A introduction under

Projects->SID->Control Unit

However, the integration of more encoders is easy.

> If so, i could use this as a skeleton for my own control

> interface, right? I’m thinking about making it in such a

> way, is this still possible if i can’t use your SID CS

> as a skeleton?

yes, you can use it as skeleton, all files which begin with

cs_ are the code for the control surface itself

> Oh, and the rotary encoders on the A3000 can also be used

> as (digital?) pushbuttons. Is something like that easily

> integrated into MIOS? Would be very cool…

just connect the terminals of integrated push-buttons like

every other button. Button changes will be notified

in sid_din.inc and forwarded to cs_menu_buttons.inc

> All the CC messages and sysex messages that i want to use,

> will have to be put in MIOS_TABLES.inc, right?

No, mios_tables.inc are a standardized way to react on up

to 256 different common MIDI controllers (like CC or notes)

which are received from the MIDI In. SysEx is not supported

by this “simple” method.

If you want to receive more than 256 values, or if you plan

to parse SysEx streams, you could to program your own handler

instead (see the *_mproc.inc file).

However, possibly you don’t want to receive data, but only

transmit data, in this case ignore this and just use your

own table format

> I looked at the snippet you posted above for sending sysex

> to the DB50XG, but i don’t understand something. Why is

> it that the number of lines in your sysex message as less

> than what it says in the DB50XG manual? In other words, You

> only input the midi channel, parameter number and the parameter

> value. In the manual it says that you also have to send the

> following sysex messages if you want to change the variation

> effect type to for instance Echo:

there are different types of SysEx messages, I used only

a small supset. The high address corresponds to the MIDI

channel so far as I remember…

> So my question is, why are there less strings/messages/whatever

> in your snippet for sending sysex to the DB50XG? And if i have

> to do it like i described from the manual, can i put all of

> these ‘blocks of messages’ into MIOS_TABLES.inc?

exactly - but never into mios_tables.inc, you have to create

your own table. Advantage: in this way you can also insert

additional infos about the parameters, for example the full

name (string), the output number format, the function which

should be called when the parameter should be sent out, etc.

Everything in one line for each parameter - this will simplify

the maintenance.

> Display question. It’s possible to display for example the

> actual delay time in ms instead of the decimal/heximal

> value on the lcd that you have to input in the sysex

> message, right?

> If so, do these tables with conversion values to ms

> (there are about 9 of them) have to put into MIOS_TABLES.inc

> or do they have to be somewhere else?

yes, you can do this by creating additional tables

(not mios_tables.inc ---- this is a standard table which can

be found in every application for some system functions, put

your own tables into another file)

Example: see cs_menu_tables.inc

> How much space is there in the MIOS to build a menu for the LCD?

Your application has about 16k, and with every BankStick you have

additional 32k. So, if there are too much strings, just copy them

into the BankStick. You could also write the whole table into

the BankStick.

> You also got an DB50XG Thorsten ( that’s what i’ve understood!),

> so you know how big the menu could be. I want almost every

> parameter to be accessed from the menu if possible.

> The menu should also diplay all correct values and names of

> effects, parameters and values. Some encoders have to control

> functions that are diplayed above them on the display as yoy

> go through the menu, other pots, encoders and buttons should

> control fixed functions. Would there be enough space in the

> PIC to implement all of this?

when you program it on a good way: yes

> One thing i don’t understand about the bankstick. Is it possible

> to implement a code into the MIOS that allows two buttons to

> directly load and save a setup into the bankstick?

you mean “into your MIOS application”

Sure - there are functions which allow you to write and read to/from

BankStick - your application can react on a button event and

do anything with the BankStick

> Or have i overlooked it and is this code already present in MIOS?

no, this wouldn’t be much usefull as this is a very application

specific function (i.E the SID Control Surface has a different

Bank management compared to a MIDIbox64 or a MIDIbox64 SEQ)

> Isn’t there any space in the PIC for saving user setups?

> Or will this space only be used to implemnt future functions?

You’ve 256 bytes in the integrated EEPROM, you could also write

into internal flash, but this depends on the space which is

required for your application itself. The MIOS program space

is reserved and will never be greater than planned (goes from

0x0000-0x3bff)

Larger setups should be saved into a BankStick

> And how is midi feedback handeled by the hardware or MIOS?

MIOS merges all incoming events with your own events when you

enable the merger with “MIOS_MIDI_MergerSet”. You only have

to ensure that you never send an incomplete MIDI event

>Do you know of any sites or ebooks that have some really

> good info for starting PIC programmers? When i search with

> google i get so many sites, i don’t know which ones are any good!

http://www.piclist.com

unfortunately not too much info about the new PIC18f family…

http://www.microchip.com

look for the PIC18F452 datasheet (especially the chapter about assembly

instructons is interesting), the PIC18F manual and the

application notes

Best Regards, Thorsten.

15

I think i’m going to wait until Step C of the control surface is finished. As i’ve understood, this would be the ideal skeleton for the display interaction. And I think i’m going to have to build my own handler.

However, possibly you don’t want to receive data, but only transmit data, in this case ignore this and just use your own table format

The DB50Xg doesn’t transmit anything, so i can’t recieve into the controller. But what do you mean with ‘my own table format’? Do you mean the table i have to make for all the sysex commands and stuff i want to implement instead of  idea i had about putting everything in MIOS_TABLES.inc. Which was the wrong solution as i’ve read now.

Can i put the conversion tables i discussed in the same file as the sysex commands? Or is this the same as you described by putting all stuff in one line for each parameter?

Couldn’t there be a permanent bankstick in case my setup is too big and i have to write it to the bankstick like you described? And couldn’t there be a second (or even more) bankstick ‘slot’ that can be used to save other things to if nessecarry?

What would happen if an incomplete Midi Event were to be recieved? Couldn’t there be something like a safety program/app that filters these incomplete messages out or some other protection method?

Thanks for the very ‘understable’ answers, Thorsten.

I listened to your tracks, some of them are very nice. That ‘Lovesong for my SID’s’ is very good stuff.

Keep it all up!

16

> The DB50Xg doesn’t transmit anything, so i can’t recieve into the

> controller.

Yep, I only gave a general statement to for the case that other

people want to realize something similar and have to write

a receiver handler

> But what do you mean with ‘my own table format’? Do you mean

> the table i have to make for all the sysex commands and stuff

> i want to implement instead of  idea i had about putting

> everything in MIOS_TABLES.inc.

> Which was the wrong solution as i’ve read now.

using MIOS_MPROC_EVENT_TABLE in mios_tables.inc

is the wrong solution for your application. The format of

this table should never be changed, since it is used by an

internal MIOS function. It should only be used if an

application has to react on simple incoming MIDI events,

in this case the table is very comfortable, and MIOS

processes the table extreme fast.

The table can also be used to get the data for outgoing

events (like shown in the ain_* and enc_* examples),

but - as I wrote - only for simple applications with <= 256

simple parameters

But four your application it’s better to put everything

which belongs to one parameter into one line: the SysEx

parameters (not the whole SysEx message, but only the

parts of the string which are different from other messages)

OR the CC parameters. A reference to the function which

sends the MIDI message (so that you can realize even more

flexible routines, i.E you could send out more than one

SysEx at once if it is required for a special menu entry).

The table line could also include the parameter name (string),

a reference to the function which prints the name, a

reference to the function which prints the value (so that

you are able to use different number formats) and finally

a reference to the register (variable) in which the value

itself has been stored.

This will be maybe more clear when you take a look into

cs_menu_tables.inc

> Can i put the conversion tables i discussed in the same

> file as the sysex commands? Or is this the same as you

> described by putting all stuff in one line for each parameter?

you mean the number conversion tables? This should be

a seperate table, otherwise it would be required to define

all displayed numbers ("  1 ms", " 1.1 ms", " 1.2 ms", …)

for every parameter entry, this would blow up the table.

Therefore it’s better if you just to add a reference to

the print function into the parameter table (like

  …, CS_MENU_PRINT_ms, …

The CS_MENU_PRINT_ms routine should use a second table

for the strings.

See cs_menu_print.inc

Here an example:

CS_MENU_PRINT_FIL_Chn
        ;; print selected channels
        TABLE_ADDR CS_MENU_PRINT_FIL_Chn_Tab
        movf    INDF0, W
        andlw   0x07
        rlf     WREG, F
        rlf     WREG, W
        TABLE_ADD_W
        movlw   0x03
        goto    MIOS_LCD_PrintPreconfString
CS_MENU_PRINT_FIL_Chn_Tab
        dw      "--- "
        dw      "1-- "
        dw      "-2- "
        dw      "12- "
        dw      "--3 "
        dw      "1-3 "
        dw      "-23 "
        dw      "123 "

> Couldn’t there be a permanent bankstick in case my

> setup is too big and i have to write it to the

> bankstick like you described? And couldn’t there

> be a second (or even more) bankstick ‘slot’ that

> can be used to save other things to if nessecarry?

A system function for MIOS which allows to select

up to 8 BankSticks which are connected to the same

line is planned :slight_smile: The handling will be very easy,

you only have to call an additional function before

you call the MIOS_BANKSTICK_Read or MIOS_BANKSTICK_Write

function. Example will follow when this function has

been integrated (the implementation is a piece of cake, but I

have to test it… ;-))

> What would happen if an incomplete Midi Event were

> to be recieved? Couldn’t there be something like a

> safety program/app that filters these incomplete

> messages out or some other protection method?

The receiver already has a savety function, I meant the

transmitter (means: the MIDI data which is sent by yourself).

You have to ensure that your program never sends out

invalid MIDI events so that the receiver on the

other side never notifies an error. Also the

merger wouldn’t work correctly in this case, it

would merge correct incoming events with invalid

events which are sent by your routine.

If MIOS receives an invalid event, the

USER_MPROC_NotifyTimeout function will be called.

> I listened to your tracks, some of them are very nice.

> That ‘Lovesong for my SID’s’ is very good stuff.

> Keep it all up!

thanks! :slight_smile:

Best Regards, Thorsten.

17

I’ve started to gather some info about PIC programmig, assembler code and took a look at the SID files.

I was wondering how much there has to be changed?

I know i have to change/make new tables with all the sysex data, LCD menu text, and assignments for the buttons/encoders/pots. But the functions for the button handeling and more stuff like that do not need to be changed right? And isn’t it so that i can delete a lot of files from the SID zip when i use Step C (new) as a skeleton for my design? Because in my design all functions are controlled via the midi out (to the midi in of my DB50XG) and in your design there’s a more ‘direct’ connection between the core and the SID, right or wrong? And also because of the fact that the DB50XG doesn’t transmit anthing back to the integrated MIOS apllication?

Some if the files are fairly understandable, but some are really difficult. The programming stuff is going to take more time than i anticipated. :cry:

18

It was your idea to use the MIDIbox SID CS as a skeleton… It’s very hard for me to tell you exactly which functions are usefull for you, which not. I tried to make the code modular, so that cs_menu_* identifies the stuff for the control surface, but sometimes I had to make compromisses (i.e.: app_defines.h includes all variables for SID and the CS part, or sid_ccin.inc is directly used by the CS code)

However, I guess that nobody but me is able to understand the complete code - it wasn’t my intention to create a learning example with the MIDIbox SID application. Some programming tricks are based on experiences I made 15 years before, it would fill a book to explain all relations :wink:

I guess that you only need ca. 25% of this code for your own application, it’s maybe better to start from scratch and to take the CS implementation only as a source of inspiration.

Best Regards, Thorsten.

19

Hmm,

Well, i’ll just have to start from scratch won’t I!!

I thought maybe i wouldn’t even have to change most of the filenames like SID_xxx.inc, because those functions would become almost the same in my application. Therefor i thought that i would only have to change little bits of code in these functions.

20

Maybe it would be the best solution for us all when I just release a downstripped version of the SID CS code (called MIDIbox TC2) which already includes some examples for the XG card. My advantage would be that I will get a perfect interface for my own XG (sooner or later…) developed by you, and your advantage will be that you don’t have to reinvent the wheel.

In this way MIDIbox TC2 would also give the basics for other customized control units.

When Do you plan to start with the hardware? :slight_smile:

Best Regards, Thorsten.