TK.

There is no need for using transistors, because digital pins will be in tristate (-> floating) once they are switched to input mode via the TRISx register. You are right! As a workaround you could connect a spare digital and an analog pin together. To measure the resistance, switch the digital pin into tristate mode. To drive the analog input, disable tristate mode and set the logic level (0/1) via LATx register This tutorial basically explains the same method I used for my STM32 based example. My example looks a bit more complicated, as it is prepared for multitasking. You want to allow multitasking for your application as well (I guess), e.g. to handle incoming MIDI data. If this isn't required, you could program it as a single thread in the Tick() hook, you could use MIOS_Delay() to insert delays between measurements, etc... Best Regards, Thorsten.

Ok, apparently the Device ID of your PIC is 70 instead of 00: F0 00 00 7E 40 70 01 F7 Solution: upload the change_id application (can be found in the MIOS download area) with device ID 70 selected in MIOS Studio. It will program a new ID, so that you can select Device ID 00 thereafter. You wrote: where did you set this? Something was wrong there... Best Regards, Thorsten.

Hi, there are several usecases for @ononly, e.g. triggering a CC or Note with the same number and a specific Velocity. Sometimes an event with value 0 is not wanted when the button is released, e.g. if you want to control a radio button element in Reaktor with multiple buttons. LEDs are not really supported for this mode, this would require a dedicated firmware which defines how the LEDs should be exactly controlled... Nothing will happen until the logic state of the switch changes... Did you already made some experiments with the firmware, or are these theoretical questions? Best Regards, Thorsten.

What is displayed in the MIDI IN Monitor window of MIOS Studio? And which operating system / MIDI Interface are you using? Best Regards, Thorsten.

Hi, sounds like a ground loop. "Starlike ground wiring" is very important here. Means: connect the ground/Vs pins of the core modules from a single point (e.g. from your PSU with separate wires), do the same for MF supply and fader ground pins. Don't chain them from one to another core module! Best Regards, Thorsten.

Thats a great case design! :) A patch/snapshot of a MB64 is not equal to the patch of a MBSID. While a MB64 patch stores pot and button positions, a MBSID patch contains sound informations in a special format. Storing a patch via SysEx request instead of the control surface is currently not supported - neither by MBSID V1, nor by V2. But it could be added with a simple hack - which MBSID version are you using exactly? Best Regards, Thorsten.

It even works without a buffer: http://www.ucapps.de/mbhp/mbhp_midi_gameport.gif Best Regards, Thorsten.

A new version is available (RC32) ChangeLog: o fixed strange Oct display output in Bassline Sequence Editor o added "DEFAULT_ENABLE_UPPER_WAVEFORMS" switch to setup_* files to enable the selection of additional waveforms for SwinSID o overworked Meter display mode in Bassline Mode (enjoy the effect! :) o changed behaviour of Play button: now it plays all SIDs regardless if they are selected or not. Dedicated SIDs can be played by pressing & holding the appr. SID buttons before pressing PLAY [/code] Best Regards, Thorsten.

I played a bit with mixed waveform based on the descriptions under http://www.dekadence64.org/sidwav.txt The results are not so promising: http://www.ucapps.de/tmp/mbsid_mixed_noise_1.mp3 demonstrates a single "F1 09 81" sequence. At the beginning you will hear a mixed waveform which quickly turns into noise. http://www.ucapps.de/tmp/mbsid_mixed_noise_2.mp3 "F1 09 81" are triggered with a definable delay (like the "Wavecomposer" is doing), which makes the mixed waveform more dominant. It's the effect which the name of the document calls "synthesized electric guitar" http://www.ucapps.de/tmp/mbsid_mixed_noise_3.mp3 I'm playing different notes to demonstrate, that the resulting sounds are not harmonic. So - yes, it's a new sound, but is it really useful? I used the WT with a hack for setting/clearing the testbit to check this. If it really would make sense to provide this as a feature, I would write a special function which resets the noise generator faster. On the other hand currently I don't see a real benefit. Best Regards, Thorsten.

It's part of MBSID V2 http://www.ucapps.de/midibox_sid_manual_b.html Best Regards, Thorsten.

The MP3 is now located here: http://www.ucapps.de/mp3/midibox_sid/mbsid_demo_random_patches.mp3 and the random patches are part of the MBSID V1 preset package. MBSID V2 provides an integrated random generator which allows to do the same without the need for .syx uploads (-> RND menu) Best Regards, Thorsten.

Update: I made a special arrangement with Ploytec which allows me to distribute GM5 devices very soon. 250 chips and 100 Mini PCBs are ordered, Nils will handle the bulk order for GM5x5x5 boards (please add your name if you are interested). Best Regards, Thorsten.

You are trying to upload the wrong file! The .hex file that you used allocates the bootloader range, the upload will be blocked so that the bootloader won't be overwritten. According to the README.txt, uploading pic18f452/midi/mios_v1_9f_pic18f452.hex is sufficient. Sidenote: it seems that it's time to remove the other .hex files, and only provide them on request to users who really *need* to update their old MIDIbox (with an installation which is older than two years) Best Regards, Thorsten.

Btw.: I'm going to arrange a special deal with Ploytec, so that it could be possible to get new GM5 chips soon, although we haven't reached the 250 pieces mark yet Best Regards, Thorsten.

Even hacking won't help here - Ploytec already pushed the chip to the limits ;) Best Regards, Thorsten.

No, the firmware can "only" handle up to 5 inputs and up to 5 outputs (it's already magic for such a small Atmel device!) You will need 4 x GM5 for your usecase Best Regards, Thorsten.

Wait until I will install SL as well ;) As a workaround I've already a simple command line tool under preparation which natively accesses the MIDI ports and doesn't require Java. It's less comfortable to use (ok, for me it's much more comfortable than clicking with the mouse), but doesn't depend on the OS version... Best Regards, Thorsten.

Seems that nobody understands me anymore the last days ;) Read this: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Ftools%2Fmk_syx%2FREADME.txt And read the comments in the config file again: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Ftools%2Fmk_syx%2Fmidibox64e.ini For Reaktor configuration, this wiki page could be interesting for you: http://www.midibox.org/dokuwiki/doku.php?id=reaktor Best Regards, Thorsten.

Thats ok for me! Go for special bulk orders in Brazil. Best Regards, Thorsten.

Yes, you only need to change the LED patterns. 32 patterns are available for each LED ring mode - they are prepared for 2 DOUT SRs per default, but you could easily change them so that only the 8 rightmost bits are used. Change has either to be done in the source code: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox64e%2Fsrc%2Fmb64e_presets.inc Or in your midibox64e.ini file, which can be converted to .syx, and uploaded via MIDI-Ox (or similar SysEx tools) once the application is running (for changing the setup w/o recompiling the source code): http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Ftools%2Fmk_syx%2Fmidibox64e.ini If they are sending relative values, the received absolute value of the same CC number will be displayed. This has to be supported by your host application (e.g. it works fine with Reaktor) - if the host doesn't send back the absolute position as a MIDI event, LED rings only make sense in absolute mode. Best Regards, Thorsten.

By destroying J1 and J2 you will get "110" as resulting configuration -> "I only". This matches with your observations. For your usecase, there was no need to remove the bridges - "000" was fine for 5 inputs and 5 outputs, and with two modules you would get 10 inputs and 10 outputs - like intended? Best Regards, Thorsten.

Thats a really clever idea! In the pre-computer era musicians reserved a track of their multi channel tape to playback the clock signal, with this AU you bring the same method to modern DAWs. Unbelievable, that nobody did this before! :) Do you think that a mode would be possible which sends a different clock pulse level for the Start signal? (I consider to write a MIDIbox application which generates a MIDI clock/start from the audio signal) Would higher resolutions like 192ppqn and 384ppqn be possible as well? And would it be possible to add an optional negative delay? This would allow to compensate the latency if the audio of the synched device is sampled by the DAW and forwarded to the Aux bus. Best Regards, Thorsten.

Hi Trevor, yes, there is a workaround: MIOS32 Device ID 0x09 will be mapped to MIDIO Device ID 1 MIOS32 Device ID 0x0a will be mapped to MIDIO Device ID 2 MIOS32 Device ID 0x0b will be mapped to MIDIO Device ID 3 MIOS32 Device ID 0x0c will be mapped to MIDIO Device ID 4 I hope that it will work, because I never tried this. Best Regards, Thorsten.

Yes, this will work! :) The LED stages of the LTC module are nothing else than two monoflops - you can connect any digital source to LTC::J1:MI and LTC::J1:MO Best Regards, Thorsten.

The technical term for such a mechanism is "force-to-scale" or "harmonizer" The application which perfectly matches with your requirements is AC Sensorizer: http://www.midibox.org/dokuwiki/doku.php?id=acsensorizer_04 There are also videos which show how it works Best Regards, Thorsten.