TK.

Hi Jerome, if you don't have programming knowledge, you would have to use a standard firmware such as MIDIbox64E Yes, it can control up to 64 LEDrings, or 41 LEDrings + 32 LEDs controlled directly from dedicated DOUT pins. If you need more, you would have to control the LEDs from a matrix (such as LEDrings, where LEDs are connected to a matrix as well) BUt it's impossible to add such an option into the existing MB64E application, you would also have to write your own application, which isn't so difficult if you know C Best Regards, Thorsten.

thanks for the feedback. It's a simple change, so it will go into the next release. thats possible with the lead engine. just step the WT with a LFO, start with a slow rate, make it faster than longer the note is played (in other words: control the LFO rate with an envelope) In the tutorial you will find a WT example which demonstrates exactly how to create such a setup. It shows how to apply the effect on a common pitch sequence, but you could also control ringmodulation/sync this way of course. :) And no firmware change is required to realize this ;) This sophisticated control of the WT via trigger matrix won't be available for the multi engine, because I want to keep it simple. Too many people complained about the complex lead engine in the past, but probably they never noticed that with the multi engine a much simpler possibility is available.... In other words: if you want to create special sound effects, it really makes sense to have a deeper look on the lead engine capabilities. Best Regards, Thorsten.

well, thats always an issue to balance the features of a sound engine. Either they are limited but easy to use, or they are so flexible that only experts can realize good sounds with it (especially sounds which can't be created with the simple ones). I know the wavetable approach of many C64 based solutions, but none of them allows to control almost any parameter of the sound, e.g. also modulators like LFO/EG... mostly they only allow to control the pitch and waveform, thats all... I really wanted this, therefore it got so complex. And now I don't really want to reduce the feature set again just that it matches with other implementations... ;) Ok, I've an alternative solution which you maybe like a bit more: an option which enables direct wave control in addition to any other parameter at offset 16 Means: you enter the sequence for any parameter change (for pitch: #249) between position 0..15, and waveform is controlled from position 16..31 if this option is enabled. Are 16 steps enough? (from my experince it should) How many steps do you need if the sound is created with the lead engine? Best Regards, Thorsten.

Hi Tonka, yes, you are right, currently only a single parameter is played in multi mode - i know that this sometimes isn't optimal, but at the time I programmed this I was a bit carefull by allocating resources to have more freedom on additional user requests. Resources are critical here, as the multi engine runs 6 independent wavetable sequencers in parallel... I can't increase the nmber of WT sequencers, and assigning WTs to instruments makes the usage more complicated than it already is, thats the dilemma :-/ I still don't know a simple solution beside of making WTs assignable to the instrument, would this be ok for you, or do you have a better idea? Btw.: does your sound work with the lead engine, or are there other issues? Best Regards, Thorsten.

no, such LEDs are not supported (they would require a different circuit and firmware) Best Regards, Thorsten.

unfortunately Kvetch did a lot of cross-posting, We should merge the articles to avoid that the discussion about the same thing is forked... I will separate the existing force-to-scale algorithm from MBSEQ V4 and provide it as a dedicated MIOS8 and MIOS32 application. There is no need for "correction tables", just have a look into seq_scale.c more than 128 scales are already part of this file, it only has to be adapted to MIOS8 since the C code isn't compatible to the lmited SDCC compiler, In addition an incoming note tracker will be required to ensure that no Note Off gets lost if keys are still played while the root or scale is changed, or when two keys play the same note (important for live situation) I expect ca. 30 minutes work on this app, So just wait till I'm back from vacation ;) Best Reagrds, Thorsten.

My reply in ca. 4 days (currently don't have access to headphones... :-/ ) Best Regards, Thorsten.

As mentioned in another posting, there will be an example soon. A little bit more patience please, we don't have a 24h programming service here. ;) Best Regards, Thorsten.

problem is, that you are impatient and spread new postings over the forum so that it's hard for somebody to determine how to answer your post (since it's hard to determine your background resp. already available knowledge) You tried to use MIOS32 code 1:1 for a MIOS8 project, this won't work without modifications. Maybe next week I will have the time to convert the example that I gave you to MIOS8. Thats a no brainer for me, it will take maybe 10 minutes... I thought that you wanted to do this by yourself, since you haven't mentioned that you never worked with C code before... But please: be patient and try to keep your postings in a single thread! Sidenote for others: the MIOS32 tutorials provide much more examples, e.g. also how to realize MIDI clock timed code for an arpeggiator. They are not compatible to MIOS8 as I think that programming on 32 bit is moe fun anyhow. Best Regards, Thorsten.

ok, i assumed that you are using 6581s since you forgot to mention this, and since 8.7V is in the good range for 8580s. There is probably no problem with the VR, it could just be a measuring error if you are using a low-cost meter (or measured from the wrong ground) Back to your original posting: could you please attach a sample where we can hear different filter modes, just to get an impression about the hum that you mean? Please also turn on/off the Ext. filter input - if enabled, you should hear a loud hum as long as no cable is connected to Audio In - nice comparison! Best Regards, Thorsten.

In the MBSEQ V4 application I've reduced the heap memory to get more space for other variables, therefore it won't be possible to add another task. But you could just hook the handler into the existing SEQ_TASK_Period1ms in app.c The input mapping won't be required, as a mapping already exists - just add an offset to the pin number, such as +128 to get unique pin numbers which can be referenced in the MBSEQ_HW.V4 file (128 = SR 17 pin 0 upwards) best regards, thorsten.

yes The scale will be selectable in a LCD menu. it will be stored in the patch structure and changed when you are selecting one of 128 patches on the main page, e.g. with a rotary encoder or with inc/dec buttons. alternatively i could add some code for selecting the scales via dedicated buttons, but i guess that you will prefer the selection via prepared patches anyhow, because multiple setup parameters can be changed at once? best regards, thorsten.

i could add this option once I'm back home. it isn't so difficult, but while the implementation will probably take 15 minutes for me, explaining how you could add this would take multiples of this time. ;) do you already know the values which have to be entered into the tables? (you could already try them out...) then i could add the prepared tables to the release. best regards, thorsten.

you could ask reboot, he sent me an acrylic window some time ago. best regards, thorsten.

hi, thats the expected behaviour. the displayed target is an additional destination for the routing path, such as LFO depth/rate, CV, MODs, etc... They can be optionally selected with the rotary encoder. best regards, thorsten.

nice ro read! :) your psu has the right specs, could it be that you are using a 6581 SID and mounted a 7809 instead of 7812 volatge regulator? (disclaimer if somebody else reads this posting without the previous ones: don't use a 7812 VR for 8580 or 6582 SIDs, they need a 7809 VR) best regards, thorsten.

i've a detailed howto at home, i will send you an individual reply via pm in ca. one week. (the update has to be done very carefully, in order to avoid that somebody overwrites the bootloader i prefer to give individual help instead of writing a 2..3..4 pages howto) please write me a pm - specify which operating system you are using (+ exact version number), which MIDI interface you are using and if you've successfully uploaded a MIOS application before. best regards, thorsten.

am geschicktesten laesst sich die scheibe wohl mit einem servomotor drehen. frage mal in einem DIY roboter forum nach, die haben evtl. schonmal etwas in dieser richtung gemacht. gruss, thorsten.

Ohne ZPM laesst sich da leider nichts machen...;) gruss, thorsten.

great tutorial, every info is correct and well explained - I really appreciate this! :) best regards, thorsten.

the hum could be caused by a too weak PSU. Check the SID supply voltage, it should be 12V on a 6581, resp. 9V on a 6582/8580 check it especially while the SIDs are plucked into their sockets and filters are turned on! best regards, thorsten.

from my experience it's unusual that the PIC is dead. it's more likely a PSU issue, especially if the voltage at MCLR# is so low. try a higher voltage at J1 - e.g. 15 or even 20V - if your PSU can't be set to such a voltage, use two PSUs in serial, or a 9v block battery in serial... Hope this helps :) best regards, thorsten

Thanks, got it! It makes sense that the leftmost encoder always changes the left boundary instead of doing strange calculations ;) Next release in ca. 2 weeks Best Regards, Thorsten.

I merged the topics...

You forgot to attach the picture, but I think that the problem is related to your DIN module(s) if a single button sends multiple MIDI events. Either a connection problem, or a soldering error. Did you already try the srio_interconnection_test as proposed on this page? http://www.midibox.org/dokuwiki/doku.php?id=din_module Best Regards, Thorsten.