TK.

Hi Nat, I tried this encoder with the non-detented modifcation, but there pulses are not clean enough for the quadrupled resolution feature. I guess that only a change in the firmware could make these encoders usable, the result would be "only" the double resolution. This change will also be required for MIOS. More infos soon. Best Regards, Thorsten.

Hi Jim, if you know a circuit to convert the sensor signals to a control voltage between 0V and 5V, a MIOS based application could help to realize this project. Depending on the number of "keys" (==used analog inputs) and the required latency, you possibly need more than one core module in order to optimize the realtime behaviour. How much sensors should be handled in parallel? By using a conversion table before sending out the MIDI event you will be able to define different response behaviours. Best Regards, Thorsten.

The enc_example3 supports 64 rotary encoders and 64 LED rings by default :) Best Regards, Thorsten.

Hi Ryan, it seems that either the PIC is not powered (did you close all 5 jumper connections at port J3?) or the crystal is not oscillating (check Q1/C1/C2). Otherwise the PIC would initialize all LEDs connected to the DOUT registers. Which crystal are you using - part number? Best Regards, Thorsten.

he builds a lot of new features into the MBSID V1.5 engine. With this version it will be possible to syncronize the LFOs, Envelopes, Arpeggiator and Wavetable Sequencer to the MIDI clock to play notes with the Wavetable Sequencer like with a keyboard to combine the arpeggiator with the Wavetable Sequencer Result: a very mighty arpeggiator :-) Here an example - a single SID with 3 oscillators plays one Wavetable (some drums from a RM1x are added later). Played notes: A snapshot from the wavetable: The MP3: http://www.ucapps.de/midibox_sid/mbsid_v1_5_wt+arp2.mp3 To be continued... ;-) Best Regards, Thorsten.

Quick inputs from my side: great idea! :) I'll join the team and provide some samples great possibility to test SID firmware v1.5 ;-) as soon as the website has been launched, I will add a link to the ucapps mainpage Best Regards, Thorsten.

Hi LO, a mixed mode (built into MIOS itself) which dynamically switches between slow and fast behaviour depending on the encoder speed is planned - maybe this will be the best compromise :) Best Regards, Thorsten.

So, which code can be seen in main.asm, line 230? Best Regards, Thorsten.

Hi Zomoipotoi, I cannot give you an adequate number as this overrun issue depends on a lot of parameters (SID sound engine load, used CC, sent notes). It happens due to a too small MIDI buffer in the PIC16F based firmware which affects the realtime capability, there isn't enough RAM free for a larger buffer. My suggestion: when the MIDIbox SID should receive a lot of external CC data, switch to PIC18F - I never noticed a buffer overrun in this implementation. Best Regards, Thorsten.

Very experimental - it seems that you've had a lot of fun, and this makes this piece interesting! :) Best Regards, Thorsten.

ooops... (fixed) Best Regards, Thorsten.

Hi Lo, for the adaption to your encoders you need to change: mios_tables.inc: the correct encoder type (detented or non-detented main.asm: set CS_MENU_USE_DETENTED_ENCODER to 1 if you are using a detented encoder for the menu cs_menu.inc: the CS_MENU_EncSpeedSet function allows you to totally customize the encoder behaviour - however, changes shouldn't be necessary there Best Regards, Thorsten.

Maybe the syntax is wrong. You can find the error messages and the appr. files/lines in "main.err" Best Regards, Thorsten.

Yes, the PSU is the same (only the colour is different ;-)) Best Regards, Thorsten.

Hi Ilmenator, the additional 7809 is used to shift the +5VDC voltage level to +14VDC. Every SID module still requires it's own voltage regulator to convert this voltage back to 12VDC or 9VDC. Without the 7809 you would get a mixed DC/AC voltage which leads to a 50 Hz hum in the background when more than one SID is connected to the PSU. It seems that this problem is also related to a ground loop, but after I inserted the regulator for a clean DC supply this humming sound is completely vanished :) To confuse you completely: the humming sound doesn't appear when all core modules are stuffed with a seperate 7805 and powered by 9VAC, when all SID modules are powered with 5VDC + 9VAC, and when the ground pins of all voltage regulators are connected together. But I got rid of this circuit due to the power consumption (-> too much heat inside the case). The new circuit brings the best results. I'm using the PSU of a C64-A (which can be seen on the pictures). I guess that PSUs from the followers should also work, if they also deliver 5VDC and 9VAC Best Regards, Thorsten. /edit: we need a FAQMARKER

Since I'm now able to test the synthesizer implementation on a much easier way (thanks of the control surface) and since the upload of code changes takes significantly less time than with the PIC16F (thanks to the bootstrap loader), I'm now able to fix some bugs/imperfections which are annoying me since months :-) Unfortunately these changes will make the sound engine incompatible with V1.4, but I think that they should be done ASAP before the first sound patches are provided by users... (of course, I will also try to integrate these changes 1:1 into the PIC16F firmware) When a LFO is assigned to OSC pitch, the intensity depends directly on the "PitchBend range" value. Higher ranges are leading to erroneous waveforms, since the modulation handler used for Finetune and the Pitchwheel is working with a logarithmic scale. In an excelent book about modular synthesizers ("Synthesizer" by Florian Anwander, I can recomment it) I read that linear frequency modulation should be the prefered method, so I will change the algorithms in this way. the LFO depth->Pitch path will get a logarithmic scale so that it is possible to control the whole frequency range of an oscillator when "depth" is set to the maximum value currently the envelope depth controls only the half range of the modulation target (e.g. of the filter CutOff frequency). It should control the whole range Filter: I noticed that the quality of the 8580 filters is much better when expected! I've programmed some kind of calibration routine which scales the filter value before it will be written into the SID register. The result sounds already better than with a 6581 - I don't want to know how this routine is working with a 6581 (haven't found the time to try this out yet). However, the "calibration" will make the sound patches compatible to both SID derivatives, and it leads to an improved dynamic range :) More about this topic in the next days/weeks ;-) Best Regards, Thorsten.

Hi Zap25, in theory you could change the time base (1 mS) of the shift register handler to any other value, just only the timer1 period register of the PIC has to be modified. But in this case also other routines like the encoder handler, the auto-repeat for buttons, the display message timer, the global timer, etc. would be called more often and this makes the solution incompatible to any other application (bad re-use). Also the CPU load would be significantly increased. Last but not least it has to be taken into accound that MIOS loads the DIN and DOUT shift registers in parallel, this makes it difficult to use the same driver for handling with a button matrix (since for this method the digital outputs have to be preloaded before the digital inputs will be sampled). There is also no reserved memory for more than 128 buttons in the system, so the whole driver cannot use the standard hooks like USER_DIN_NotifyToggle In fact it would make more sense to write a dedicated shift register driver for such a matrix and to connect the registers to spare pins (if available). This driver could be hooked to the USER_Timer (the only standard timer provided by MIOS). The registers which are necessary to save the state of the buttons and maybe also the debouncing timers have to be located into the memory region which is reserved for the application. Best Regards, Thorsten.

Hi Steven, the term "wavetable" is an artefact from the good old C64 days. It has nothing to do with audio samples, but with CC controllers which are played sequently - so fast, that the resulting noise sounds like a new waveform. There is a lot potential in this kind of synthesis, especially when you are able to control any parameter (not only the pitch, the waveform, the sync/ringmodulation switch, but also LFO/envelope/filters and also the wavetable CC assignments and the rate --- really any parameter) like with the MIDIbox SID ;-) Here are four short preset examples: http://www.ucapps.de/midibox_sid/mbsid_wt_demo.mp3 First three sound patches: the wavetable rate (speed) is varried from 0 to 119 Last sound patch: this is one SID playing one patch - it should demonstrate that wavetables are not only usable for C64 like drum sounds. Best Regards, Thorsten.

Thanks Frank, the four points are a nice abstract of my goals. I've also the same oppinion about DIY like you wrote, but I think that I should also clarify what the GPL means: it opens the design also for commercial parties. Pilo: the GPL says that - from the legal point of view - these projects can be distributed, modified and re-used for other projects. They could also be used for commercial products so long as the terms of the GPL are not violated. In fact this means: if a big company would build and sell MIOS based MIDI controllers, they would have to publish all the stuff which is necessary to reconstruct the complete product (with all it's improvements) for free. An improbable Example: if Yamaha would start to build MIDIbox SID clones with cost-optimized PCBs, an improved circuit and usefull application enhancements, they would have to publish the results also under GPL - it would be a benefit for us all. However, Yamaha would never do this, as other companies could use these sources to offer an even cheaper MIDIbox SID for less profit. In theory... the other side of the story is my willing to support people who want to commercialize my projects. As MIDIbox should stay a hobby project for myself, I will spend no minute to give design & programming hints for those peoples - even for a fee, as my sparetime is more valuable than money. I will also not help a user (consumer) who bought a ready made MIDIbox for the same reasons. Robotfunk: please don't take this statement as personal attack against you (I played with your software a time ago, it's a really usable and mighty tool! :-)) - I will just prevent any additional effort for myself before a "go" decition triggers an avalanche of requests from other interested parties (I refused all requests successfully in the last years). If you want to sell MIOS based controllers, then do it, but please don't expect any support from my side, and make all the project sources free available. Steve: what you are doing is 100% accepted from my side so long as you help these people if they notice problems with the design. One last statement to this issue (summa summarum): I don't like commercial MIDIbox products and I will ignore any request, but the GPL allows others to sell ready-made MIDIboxes under the circumstances which are listed under http://www.gnu.org/copyleft/gpl.html To the first question - I don't see the possibility for a MIDIbox Convention in the next months, especially because we are spreaded other the whole world (think about the traveling costs... ;-)) but maybe we could try an online conference via IRC or a tool like Netmeeting one day. :) Best Regards, Thorsten.

Age: 0x1e ;-) Other RPGs: no. In fact I never played Avalon, I'm just only one of the administrators and programmers ;-) (but I'm not active anymore). We started this MUD 1994. It was a great time, I learned a lot about the internet, object oriented programming, teamwork and topics like "find a bugfix as fast as possible so that the 3-head firedragon doesn't eat up so much players during lunchtime" ;-)) Best Regards, Thorsten.

No, I'm still at home ;-) Best Regards, Thorsten.

Unfortunately not - the sound chip of the VC20 (called VIC) is very primitive compared to the SID and it isn't compatible. Best Regards, Thorsten.

Hi Nat, yes, the enc_example3 shows how to drive up to 64 LED rings. Of course, the same routine could also be used for MIDIbox TC, although only one LED ring should be driven :) Best Regards, Thorsten.

My advice: don't use MPLAB as it makes everything more complicated than required ;-) The main.asm file can be assembled directly with MPASM: MPLAB IDE/MCHIP_Tools/mpasmwin.exe Just click on this program (make a shortcut on your desktop) and load the main.asm file. The result will be a "main.hex" file which can be converted within the DOS shell by executing "convert.bat" (Perl must be installed) to a main.syx file. The source files (main.asm and all *.inc and *.h files) are editable with your favourite text editor. I prefer emacs, but there are also some other usefull editors especially for Windows available on the net. Especially "code highlighting" is an important feature, so that comments can be regognized easier. Best Regards, Thorsten. P.S.: Ian - I've received the encoders last week - thanks again!! :)

Yes Ilmentor, and this jitter will be especially appear in the region where the output curve of the logarithmic pot has it's highest increase rate where a sampled voltage value changes between 4V and 5V without moving the pot. However, the implementation of a scale table is very simple, especially if only 7bit values should be converted. Insert a table into your source code with 128 values: Conversion_Table db 0x7f ; value #0x00 db 0x7e ; value #0x01 db 0x7d ; value #0x02 [..] db 0x01 ; value #0x7e db 0x00 ; value #0x7f Now you can convert a pot value in this way: ;; 7-bit pot value saved in TMP1 ;; move converted pot value to TMP2 TABLE_ADDR Conversion_Table movf TMP1, W ; get pot value 0x00-0x7f TABLE_ADD_W ; add WREG to table pointer tblrd*+ ; read from table movff TABLAT, TMP2 ; copy table entry to TMP2 Best Regards, Thorsten.