TK.

to make it clear: all external functions of the MIDIbox SID can be controlled in the menu too, just only for the SID, Link, CC and Edit button I decided to do it not, since the handling would be so circuitous, that it wouldn't make fun anyhow. This was my decition during the design phase, and it's some effort to overwork parts of the CS handler in order to allow alternative controling methods of these functions. In MBFM I did this (there is a special page which pops up when the CFG button is pressed - it allows you to control 8 special options), but I don't really want to do this again for the SID for various reasons. In other words: for you it's just for temporal comfort, for me it means: overworking and testing code, releasing it, support it in the future (before each release I have to try, if this feature still works), and answering additional questions about such "bad documented features" in the forum over the next years. Just to give you an impression, why I always try to reduce complexity. Believe me, it costs less time if you would just drill the holes! in the debug window of MIOS Studio, you are able to write directly into the memory of the core with the "SRAM Write" command. The "CS_MENU_SELECTED_SID_FLAGS" variable is located to 0x46 (please doublecheck this address in app_defines.h) write 1 to this address: SID 1 is selected write 2 to this address: SID 2 is selected write 3 to this address: SID 1 and 2 are selected Not sure which are the optimum settings for this encoder, you could try a different encoder type (see mios_tables.inc) or you could try different settings for CS_MENU_USE_DETENTED_ENCODER and CS_MENU_ENC_SPEED_VALUE (see main.asm) Best Regards, Thorsten.

No, link just means that the master will forward incoming MIDI events to the slaves. All of these options makes sense in daily work with the SIDs, but it's not a good idea to hide them deep in the menues. Therefore I wrote an explicit hint about this requirement at the StepB page. Once you have the buttons available, you know what I mean :) I strongly suggest to add these buttons - you still have some DIN pins free, which means, that there is no "resource problem" which prevents you from doing this. Best Regards, Thorsten.

Lies Dir doch einfach nochmal das Posting von Raphael richtig durch Gruss, Thorsten.

http://www.maybites.ch/tikiwiki/show_image.php?id=68&nocount=y Ooof! Best Regards, Thorsten.

Hi Jeroen, the easiest way is to program this directly into the USER_ENC_NotifyChange hook. Check for the encoder number (it's in MIOS_PARAMETER1), if it matches with the encoder you are using for pitchbend, don't branch to MB64E_ENC_Handler, but continue with your own routine. For a "cheap" timer I would suggest the use of USER_SR_Service_Prepare or USER_SR_Service_Finish, these routines are called each mS. Here you could add a counter (free register address has to be found and defined in app_defines.h) which decrements a value until it reaches 1(!) This gives you following possibilities: in the USER_ENC_NotifyChange hook, check if the counter is <= 1. If this is the case, send the Note On event with velocity 0x7f always set the counter to 255 (so that it reaches 1 after 255 mS) and send the CC events depending on the direction (-> MIOS_PARAMETER2, read the comments of the hook) in USER_Tick (called when nothing else is to do), check if the counter has reached 1. If this is the case, set the counter to 0 and send the Note On event with velocity 0 (-> Note Off) thats all! :) Additional hint: just make the first tries with the MIOS C wrapper. This should shorten the time to success. Once you've found a working code, you can translate it to assembler. I guess that it will result in ca. 30 additional assembly instructions. Best Regards, Thorsten.

Hi Flo, no, thats not possible. Do you want to change the CV setup very often, or is it ok for you to do it only once (when the LCD is connected to the MBCV core)? Best Regards, Thorsten.

see the description of the SID buttons: http://www.ucapps.de/midibox_sid_csB.html "SID1-4: Use these buttons to select the SID(s). They behave like "radio buttons" if only one is pressed so that you can quickly change between the SID setups. It's also possible to select multiple SIDs by holding one of the SID buttons and pushing the additional SID buttons - in this case every parameter change will be sent not only to one, but to all selected SIDs." Parameter change means in this case: not only the CC parameters, but also the patch once you change it. Best Regards, Thorsten.

Diese Selbstbau-Oszillatoren sind nicht stabil genug, vor allem das Anschwingen macht Probleme. Ich habe anfangs auch damit herumexperimentiert, siehe http://www.midibox.org/forum/index.php?topic=3469.0, nicht ohne Grund findet man auf meiner Homepage keine Referenzen zu solche Basteleien. Es macht wirklich keinen Sinn, sich einen Maxim Chip anzuschaffen, nur um die 2 Euro fuer einen integrierten Oszillator zu sparen. Gruss, Thorsten.

You've to enable the MIDI merger - this is normaly done with the Link button. So long it is not available, you could either enable the Merger via MIOS Studio (see Debug window), or you could recompile the code with CS_MENU_DEFAULT_LINK 1 (see main.asm) Best Regards, Thorsten.

Hallo, da sich Dein Setup teilweise auf dem PC befindet, wuerde ich Dir empfehlen, die Transponierung von Noten auch dort vorzunehmen. Mit http://www.midiox.com sollte das machbar sein Damit laesst sich dann sogar der Roland D20 transponieren - hierfuer muesste der Synth in den "Local Mode" geschaltet werden (wie das genau funktioniert, muesste in der Bedienungsanleitung stehen). Im Local Mode sendet die Tastatur nur noch MIDI Events, der Klang wird jedoch nicht direkt gespielt. Dieser laesst sich dann nur noch ueber MIDI ansteuern. Mit einer Loopback-Schleife MIDI In->MIDI Out muesstest Du den Klang also wieder hoeren. Wenn Du nun das MIDI Signal nicht direkt rueckschleifst, sondern ueber MIDI-Ox, welches auf dem PC laeuft, kannst Du von dort auch die MIDI Events umwandeln, und somit die Transponierung vornehmen (dies laesst sich dann via Knopfdruck auch umschalten). Von MIDI-Ox aus kann man die MIDI Events dann auch auf andere (virtuelle) Instrumente weiterleiten Gruss, Thorsten.

Hallo Pico, ich habe mit dem CCS noch nicht gearbeitet, evtl. musst Du der Variable ein spezielles Attribut mitgeben, damit sie nicht in das "unbanked" Memory (<0x80) abgelegt wird? Oder Du weist der Variablen einer bestimmten Sektion zu (deren Namen du frei waehlst), und lokatierst diese an die gewuenschte Addresse (gibt es ein Locator-File?) Im Zweifelsfall sollte der direkte Memoryzugriff wie folgt funktionieren: (*((volatile unsigned int *)(0x400))) = 0x12; // schreibt 0x12 nach 0x400 Ich mache mir daraus immer ein Macro: #define MEM(register) (*((volatile unsigned int *)(register))) so dass ein direkter Speicherzugriff wie folgt funktioniert: MEM(0x400) = 0x12; CCS und USB: gehe mal nach forum.microchip.com, klicke auf "search", tippe "ccs usb" und waehle (das ist der Trick!) "Time filter: All Topics" an Gruss, Thorsten.

Hi Robin, great! thats the right way Best Regards, Thorsten.

Hi Kokoon, because without a BankStick you would only be able to store a single Patch, but a Drumkit consists of 21 patches... In the meantime I found a solution: it's now possible to stop an envelope immediately, with the effect that the result is more reproducible. 00 will be written into the ADSR registers of the SID, if a wavetable sequence is stopped with "END 7F" Here an example: Track 1 assigned to Waveform Track 2 and 3 not used in this example ((don't assign a track to the VCA envelope anymore...) Wavetable: [tt] Step Trk1 Comment 01 PLAY 01 Switch to Triangle 02 PLAY 08 Switch to Noise 03 PLAY 04 Switch to Pulse 04 PLAY 04 Hold Pulse 05 PLAY 14 Release Gate 06 PLAY 14 let Gate cleared 07 PLAY 14 dito 08 END 7F stop Wavetable and clear VCA envelope [/tt] set attack to 0, decay rate very short, sustain low, release high Now you can control the volume with following parameters: VCA decay, sustain and wavetable rate Another advantage of this method (clearing the envelope registers) is, that it fixes the envelope bug of the SID in most cases. It's still possible to provoke the "hick ups", but only, if the notes are played so fast, so that the envelope registers are not cleared between two notes. There must also be a delay of ca. 20 mS between two notes in order wait until the envelope is "seddled". But so long this is guaranteed, the SID output is more reproducible now :) Here a link to the release which features this function (I will build this also into the main MBSID firmware to keep it compatible) http://www.ucapps.de/mios/mbsid-d_alpha2.zip Best Regards, Thorsten.

Hi Robin, Based on my code I can show you a working solution very quickly. Just define, that group1_selected gets a special value (e.g. 0xff) if the selected button has been pressed a second time. As an effect, all LEDs will be turned off. Once you press the same button again, the routine will work like pressing any other button... So, here the modification: unsigned char group1_selected; void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam { unsigned char i; // DIN 16..31 is one "radio group" if( pin >= 16 && pin <= 31 ) { // if button is already selected, turn off all LEDs // this is identified with group1_select == 0xff; if( group1_selected == (pin - 16) ) { group1_selected = 0xff; // all LEDs off } else { // save the selected button function of the group group1_selected = pin - 16; } // the LEDs of this group are connected to DOUT Pin 0..15, clear them for(i=0; i<=15; ++i) MIOS_DOUT_PinSet0(i); // set the LED which is related to the selected function if( group1_selected != 0xff ) MIOS_DOUT_PinSet1(group1_selected); } else { // this branch handles DIN 0..15 and DIN 32..127 } } [/code] Best Regards, Thorsten.

Fine - so just call your functions from MCLOCK_Tick() in mclock.c - it contains all events you need to control a sequencer (Start/Stop/Pause/Clock) :) Best Regards, Thorsten.

V1.5 doesn't work with the current interconnections between CORE and SID. IS THIS A JOKE? Please read my last posting again - all the answers to your last questions are explained in the walkthrough, why do you ignore this document? Karma -1

Which tests that are listed in the Walkthrough are working? -> http://www.ucapps.de/midibox_sid_walktrough.html Best Regards, Thorsten. P.S.: the firmware has reached V1.7! Where did you find a v1.5 version?

I will keep this in mind for the case that I feel boring ;-) Shuffle function: the outgoing clock has to be delayed with the same patterns used in MBSEQ 48ppqn: timer has to be invoked with double frequency, 48ppqn pulse has to be generated on each tick, MIDI clock has to be sent on each second tick 4 ppqn: requires a clock divider Read clock and convert it: similar to MBSEQ (must work like a PLL (phase locked loop)) Best Regards, Thorsten.

Unfortunately I'm not able to release a complete MBSID-D yet, since the reprogramming of the control surface is much more effort than expected - the whole engine is programmed on a different way now, and this requires conceptional changes in the CS handling. However, on the other hand the engine itself works pretty well, therefore I've uploaded a prebuilt alpha version (binary only) which should give you the chance to optimize your drum patches, and to combine them to complete drumkits: http://www.ucapps.de/mios/mbsid-d_alpha1.zip This package also includes the drumpatches which I've received so far from Kokoon, Rio and Illogik. Plus my own drumkit which contains some Hubbard-like drums Here a short preview: http://www.midibox.org/midibox_sid/mbsid-d_demo2.mp3 As "alpha1" should indicate, the firmware is definietly not final. Editing patches is currently a little bit tricky: you can play the currently edited patch with MIDI Note C-2 of Drumkit 1. Once the patch is finished, you can upload it to the final patch location with Right Click->Store The patches are assigned to Note C-2 ... G#3 (21 drum patches) Each bank contains 6 drumkits, they can be selected with CC#0 (and not with Program Change yet, since this interfes with the JSynthLib "Play Patch" function) - as a final solution, I propably have to create a Drum specific JSynthLib module... However, hope that you have the same fun with this release like me - I'm going to create much more drum sounds today :) Best Regards, Thorsten.

Hm.... which voltages do you read exactly? I mean, sometimes people measure 13.9V, and then they think that this could be a problem... but it's just within the allowed tolerance. If the core gets a voltage much lower than 5V if the SID module is connected as well (lets say 4V or even lower), then there must be a short circuit on the SID board. Check it visually, sometimes small solder clumbs can cause such an effect. Remove also ALL ICs when doing such checks, thats very important! First try to get the Core module running like described in the SID Walkthrough. Once it works, you know, that the problem cannot be located at there. Best Regards, Thorsten.

Are you using the PSU of an "old" C64 (which contains the 6581), or of a C64II (which contains the 8580)? Best Regards, Thorsten.

Hi Robin, you could save the last pin number in an additional global variable (just call it 'unsigned char last_pin;') Alternatively you could declare the variable within the function, and make it static ('static unsigned char last_pin;') - static variables don't loose their value when the function is called again, and the variable name is only in the scope of this function, which means, that you can use simple names without the danger for conflicts with other global variables. Thats perfect, I wouldn't do it on a different way This leads only to additional execution time (due to the if condition), and to larger code. Something that isn't clear to me is the relation between the XOR toggle and the subject "Radio group button behaviour". So long you only want to set a certain pin, and clear the others, then I would suggest following solution: unsigned char group1_selected; void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam { unsigned char i; // DIN 16..31 is one "radio group" if( pin >= 16 && pin <= 31 ) { // save the selected button function of the group group1_selected = pin - 16; // the LEDs of this group are connected to DOUT Pin 0..15, clear them for(i=0; i<=15; ++i) MIOS_DOUT_PinSet0(i); // set the LED which is related to the selected function MIOS_DOUT_PinSet1(group1_selected); } else { // this branch handles DIN 0..15 and DIN 32..127 } } [/code] So, as you can see, for a group of LEDs, where only one lits, you don't need to store the information in an array, you only need to store a reference to the selected function Best Regards, Thorsten.

Hi Robin, no, you don't need an "int" for a for statement, "char" or "unsigned char" will work ok, and they are much faster anyhow (16bit always produces additional code, which is mostly not required) So, I guess that your main question is, how to store the last state of a button or LED. You can do this in the same way like described here: http://www.midibox.org/forum/index.php?topic=5662.0 Only difference is, that you don't toggle the array entry, but just set or clear it Best Regards, Thorsten.

mainly it's intented for MIDIbox users, but of course, you can also ask general questions. In this case it's just useful to know, that you are not using a MIDIbox (in this case I would at least know, that it wouldn't be a software problem ;-)) So, I guess that you are having two main issues. Software issue: you have to eliminate the 1/2 bit LSB error of the ADC. The easiest way is to propagate value changes only, when the difference between the last, and the new sample is higher than a certain value. By doing so, you will create some kind of deadband, in between changes are not sent (in MIOS this feature is configured with MIOS_AIN_DeadbandSet). Then higher the jitter, then higher the required deadband. A deadband will reduce the resolution, but for common MIDI values (which are 7bit) this doesn't matter anyhow. Hardware issue: do you have a schematic of your circuit? Best Regards, Thorsten.

By using SID_CCIn you are sending the parameter change directly to the sound engine of the master core, but not to the control surface (which runs in parallel to the sound engine). Therefore this method doesn't allow you to forward changes to the slaves. This could be realized in different ways, but all solutions lead to side effects, which are propably not wanted. Solution 1: send the same CC#s over the MIDI interface (-> MIOS_MIDI_TxBufferPut). Disadvantage: if slaves are assigned to the same channel, they will update the parameters at the same time Solution 2: send parameter changes via SysEx (see the SysEx implementation chart) Solution 3: don't use SID_CCIn, but forward joystick movements to the CS_MENU_MS_SendParameter function (not selfexplaining usage, bad documented). In this case, the SID has to be selected in the CS_MENU_SID variable Solution 4: use the same approach like CS_MENU_ENC_CS_Change_Menu, so that a joystick is handled in the same way like an encoder Best Regards, Thorsten.