TK.

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.

Very clever! Thanks for the inspiration! :) Very difficult, as CC processing consumes too much time. But I will think about a "slow-path" solution. Best Regards, Thorsten.

The SID volume can only be controlled with 4 bit resolution, in addition you will notice a crackling sound (which was mis-used in the past to play samples) So, controlling the volume is no suitable option. You could control the cutoff frequency though. Or an external VCA controlled via an AOUT module (-> expensive, but you asked for this) Currently CC#11 isn't assigned to any parameter (for good reasons, because controlling the 4bit volume could be annoying), but you could do this in src/sid_cc_table.inc If you are using the Multi Engine, the note stack allocation algorithm will cleverly assign voices automatically like a polyphonic instrument :) The multi engine allows you to assign voices to different MIDI channels, so that no second MBSID is required. E.g. you could assign the three voices of the "left channel SID" to MIDI channel #1, the other three voices of the "right channel SID" to MIDI channel #2 Thats possible as well, the Multi Engine is very flexible! Best Regards, Thorsten.

Beta42 is available now (with less features than planned, but I thought that it would be better to release the bugfixes with higher priority) MIDIboxSEQ V4.0beta42 ~~~~~~~~~~~~~~~~~~~~~ o Handling of Start/Stop/Pause button changed for Slave and Auto Mode to allow proper synchronisation to the measure when multiple sequencers are playing together. Whenever a MIDI clock is received: - the STOP button won't stop the sequencer, but just disables the output of all tracks (like a Mute). The step progression continues to run. - the START button won't start the sequencer immediately. Instead MBSEQ will wait for the next measure and then enable track output again. - the PAUSE button will enable/disable track output, but the track progression continues to run. In order to notify that track outputs are disabled, the START/STOP/PAUSE LED flashes to the beat. o Added Live page. The page can be entered by pressing UTILITY -> Live (GP Button #11) Inside this page notes (and drum instruments) can be played with the GP buttons. In addition the 4 MIDI IN Busses for Transposer/Arpeggiator/Live Playing can be configured like in the MIDI page. Following Live Play parameters are available: - track selection - track mute/unmute - Octavewise transpose - Velocity (only used for GP button keyboard) - FTS (Force-To-Scale) - FX on (enables Humanizer, LFO, Limiter and Echo) Note: the Echo effect will only work when the sequencer is running! o parameter layer mutes are now also working for velocity/length/probability/delay/roll/roll2 o Echo Fx now also works with "zero delay". In conjunction with the Note incrementer and (optionally) force to scale this results into a "poor man's chord" mechanism. ;-) o Move function works beyond step 16 as intended again [/code] Sorry, I wasn't able to reproduce this I tried to improve this a bit, but without much luck. The problem: Cubase sends the note event after the MIDI clock event, accordingly the transpose function will restart the track after MBSEQ processed the first step. In Logic I'm able to apply a negative delay to the events which are sent to MBSEQ, this solves the issues at my side. This is the recommended approach anyhow, you would do the same when controlling (for example) the arpeggiator of an external synth which is synchronized to the MIDI clock. Best Regards, Thorsten.

Progress - hooray! :) Since Nils is currently too busy for handling this bulk order, Marco aka. Schrittmacher will take over the (very time consuming!) task. He will contact all people in the list today or tomorrow. Best Regards, Thorsten.

Hooray! :thumbsup: Best Regards, Thorsten.

These is really a special setup! :) I wrote a small application which demonstrates how a MIDIbox Link Endpoint can be handled: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fquickies%2Fmidibox_link_ep%2Fapp.c Most important part is the filter handling: ///////////////////////////////////////////////////////////////////////////// // This hook is called when a MIDI package has been received ///////////////////////////////////////////////////////////////////////////// void APP_MIDI_NotifyPackage(mios32_midi_port_t port, mios32_midi_package_t midi_package) { // toggle Status LED on each incoming MIDI package MIOS32_BOARD_LED_Set(1, ~MIOS32_BOARD_LED_Get()); // MIDIbox Link Endpoint Handling: // activate filter when 0xf9 has been received // deactive filter when 0xfe has been received // this is only done for UART ports if( (port & 0xf0) == UART0 ) { if( midi_package.evnt0 == 0xf9 ) { midibox_link_filter_uart |= (1 << (port & 0xf)); return; // control word received: don't forward, exit! } else if( midi_package.evnt0 == 0xfe ) { midibox_link_filter_uart &= ~(1 << (port & 0xf)); return; // control word received: don't forward, exit! } // exit as long as filter is active if( midibox_link_filter_uart & (1 << (port & 0xf)) ) return; // filter active... } // forward any UART to USB0 if( (port & 0xf0) == UART0 ) { MIOS32_MIDI_SendPackage(USB0, midi_package); } // forward USB0 to UART0 if( port == USB0 ) { MIOS32_MIDI_SendPackage(UART0, midi_package); } } [/code] The forwarding method has to be adapted depending on how you organized your MIDI setup Best Regards, Thorsten.

I haven't added this feature to MIOS32 since multiple MIDI INs are available, so that chaining isn't really required anymore. Instead you can use a starlike wiring. To give you a more sufficient answer, I would need to know, how many cores are you planning to connect together? Best Regards, Thorsten.

I will add mutes for these parameter layer assignments as well, shouldn't be a big task, and it seems to be useful :) Best Regards, Thorsten.

This seems to be a bug in SID_RND_GenerateOsc you could try to debug this in src/sid_rnd.inc, or just wait for the next release :) Best Regards, Thorsten.

Especially stupid posts shouldn't be removed to avoid that other people are doing the same stupid errors. (and this happens more often than doing unstupid errors! ;) Best Regards, Thorsten.