TK.

Fortunately not - the menu handling doesn't require navigation buttons. Pages are selected directly via ALT+<gp button> and EDIT/SONG/PATTERN/MUTE buttons Best Regards, Thorsten.

See also: http://svnmios.midibox.org/trunk/apps/sequencers/midibox_seq_v3/src/j5_dout.inc (which can be optimized, yes... it's quite old. And it's better to use PROD[LH] as temporary registers than MIOS_PARAMETER[12]) The official j5_dout module will get a C wrapper, similar to this module: http://svnmios.midibox.org/trunk/modules/iic_midi So that it can be used by asm and C programs.... Best Regards, Thorsten.

But the MIOS based IIC access methods are working very stable since years, why should the internal peripheral work better? There are several reasons, why I'm not using it (also historic reasons...) - one reason is, that the I2C pins can change between PIC derivatives, and mostly allocated by other useful functions. So, I don't see any reason,w hy using the înternal SPI! Best Regards, Thorsten.

Using the bitbanging method was a design decition, which cannot be changed anymore. However, why do you need multi master support? Best Regards, Thorsten.

Thats strange, because according to your "user permissions" overview, you should be able to reply. Does anybody notice similar issues in the past? Best Regards, Thorsten.

The first beta version can be downloaded from the bottom of this page (press refresh button of your browser if you don't see the .zip package): http://www.ucapps.de/midibox808.html It's already working quite stable, and I had some fun with it. You *must* try out this: - press&hold EDIT button - select LC/MC/HC tracks - change to random page with ALT+GP button 12 - press one of the GP buttons to generate random patterns until it sounds nice - change to progression page with ALT+GP button 7 - press GP button 5 (Fwd: 5) and 11 (JBack: 3) - enjoy the sequence, and don't forget to switch between A and B section MIDIbox SEQ V3 users who want to evaluate the firmware can upload the setup_808_mbseqv3_hardware.hex firmware. The default pattern setup outputs MIDI events at Channel #10 (General MIDI drum map is used) Please read the warning about Mixer BankSticks if your one isn't connected to CS2! Best Regards, Thorsten.

Theoretically this is possible by switching the four data lines of the SRIO chain (RC/SC/DI/DO, Vss and Vdd can be shared between the core modules), because they are "hot-pluggable". So, you could use the same encoders, buttons and LEDs for both cores. Sharing a LCD is not so easy, on the other hand you could left it out for MB808, or you could connect a small 2x16 LCD to the MB808 core (which makes sense for people who prefer a direct visual feedback when handling menu pages - like me) Best Regards, Thorsten.

Due to this "power-up behaviour", it could make sense to handle the error flags (FERR and OERR) correctly - once integrated into your small test loop, check again if RCIF is still flagged after RCREG readout. FERR: whenever set, it should be cleared by software OERR: whenever set, disable the receiver with CREN=0, thereafter enable it again (CREN=1). Overrun errors should be notified somehow by your program, e.g. a LED could lit - very useful for debugging. Best Regards, Thorsten.

Btw.: it wasn't the first time where you mixed Tx with Rx, see also the TRISC initialisation: // 10001110 (C7 = TX input, C6 = RX output, C<5,4> outputs, C<3,1> inputs, C0 output) TRISC = 0x8E; [/code] RC7 is the Rx input, and not Tx output (however, the TRISC configuration itself is ok) My statement "SN75176 is powered by the Tx line" was wrong, and therefore confusing. I overlooked the connection to Vdd. The schematic is very hard to read on my screen! :-( Btw.: a pull-device doesn't make much sense on an output pin. ;) You are writing, that Rx is low when no transmitter is connected to the bus. But the required idle level of Rx is high! A low level will be detected as a start bit, and if it is permanently low, the UART will receive multiple bytes with frame error (FERR flag set) due to the missing stop bit. RCIF will be set as well in such cases, this matches with your observations? If this doesn't make sense to you, just have a look into the PIC datasheet, e.g. search for the "Asynchronous transmission" diagram (figure number depends on datasheet version, it is figure 16-2 of DS39564B) Since it isn't clear to me, if your schematic and/or descriptions about observations are complete and correct, I will stop speculations and wait for an answer ;) Best Regards, Thorsten. P.S.: please doublecheck, if the Rx terminal is connected to pin RC7 of the PIC, and not RC6

In order to understand the schematic better, I have to ask a question first: why did you pull Rx to low-level (Vss)? The SN75176 is powered by the Tx line - if a frame is transmitted by the PIC, the chip will loose power, Rx will "see" Vss, and the UART will detect a start bit. Accordingly RCIF will be set after short time. Probably RCSTA.FERR will be set as well (frame error) if Rx pin is not in idle state during stop bit phase. Best Regards, Thorsten.

Instead of military service, I served in a school for physically handicapped pupils. Beside of some supporting jobs, I gave computer and music lessons. I also developed some dedicated sensors for replacing a mouse or computer keyboard, etc - was really a great time, that I don't want to miss. So, thats really a contrast to military service ;) Best Regards, Thorsten.

The problem is, that the Wiki configuration tool doesn't display the access group name. So, instead of comfortably enabling "Delete" permission for "Frequent Writer" group, I get "Group 1", "Group 2", "Group 3", ... "Group 9" presented, and can only make a guess if you are in the appr. group or not... I changed this now for "Group 9" - please check. If it doesn't work, we need to test other groups. Best Regards, Thorsten.

You could use the 4x16 Button/Duo-LED application: http://www.midibox.org/forum/index.php/topic,10476.0.html It's designed for much more control elements, but nothing prevents you from connecting a smaller button matrix (even without LEDs) Best Regards, Thorsten.

This is a programming example for sending data over IIC: http://www.ucapps.de/cmios_fun.html#MIOS_IIC_ByteSend The IIC slaves have to be connected to J4 of the core module Best Regards, Thorsten.

A Tap-Tempo function is planned for MB808, the same routine will be integrated into MBSEQ later Best Regards, Thorsten.

yes yes - you can use it in an original C64 as well, it should even work with other SID synths like HardSID I cancled this quick idea, and designed the firmware for 4 stereo pairs only. You could use two MBSID stuffed with 16 SIDs - it would require two control surfaces, and multi poly wouldn't work over two boxes. However, do you really think that you need so many SIDs? Just waiting for the guy who demands for a 32 SID option, but only to have some soldering fun instead of making music. And the next guy, who thinks that 64 SIDs would be even more cool, because he likes the supersaw sound ;) Best Regards, Thorsten.

The HardSID synth engine runs only on a PC, and not inside the HardSID device - so thats how the "MIDI/Audio chain" would look like: [pre]Mac ~~~~ USB/Firewire/Card -> MIDI Out -> MIDI In -> USB/Firewire/Card ~~~~ PC ~~~~ VST Host ~~~~ VSTi ~~~~ USB ~~~~ HardSID -> Audio Out -> Audio In ~~~~ Mac [/pre] You can consider, that each "~~~~" adds a delay (no issue, can be compensated), but also Jitter (very ugly, cannot be compensated) For comparison: the MIDI/Audio chain of MBSID: [pre]Mac ~~~~ USB/Firewire/Card -> MIDI Out -> MIDI In ~ MIDIbox SID -> Audio Out -> Audio In ~~~~ Mac [/pre] Note that the effective Jitter/Delay can be easily measured with a scope the following way: periodically play a short test tone from the Mac through a soundcard, and another with the SID. Compare the offset and the jitter between the two waveforms. Alternatively you can use the record function of your DAW (but delay measurement wouldn't work reliable enough, if there is an inbuilt latency compensation - however, you should be able to measure the jitter) Best Regards, Thorsten.

Hallo Tobsen, wie lang sind eigentlich die Kabel zu (und zwischen) den einzelnen Modulen? Encoder-Problem: hast Du schonmal einen zusaetzlichen R+C am Ende der DIN-Kette ausprobiert? Gruss, Thorsten. P.S.: weitere Erfahrungsberichte wuerden mich sehr interessieren

Yes, according to http://www.ucapps.de/midibox_sid_manual_up.html you only need to add the additional 1k pull-up resistor (R12) Best Regards, Thorsten.

HardSID is cool, yeah! It provides many features which can never been realized with a MIDIbox SID, especially now where the update rate has been dramatically increased. But from the concept point of view, there aren't big changes compared to the previous HardSID versions, therefore I'm a little bit surprised about the hype around this product update. you still need a PC to access the SIDs (I guess that the main reason, why they provide a USB version now is, that many musicians are working with notebooks meanwhile). the device itself is "stupid", it relies on the host software which is handling the "synth engine". too bad, if the soft- or hardware is not working anymore on future Windows versions, and the company discontinues support software runs on Windows only, no Linux or MacOS support even if the Linux community starts to develop a driver like they did for HardSID PCI: it will only play .sid tunes, or maybe give you simple MIDI access to SID registers - but thats all (developing a performant engine can take years) SID audio outputs are still not sampled internally, you still need a soundcard to feedback the audio to your PC (don't expect an integration like known from Virus TI) - so, all they did was replacing PCI by USB we all know, that USB is not good for audio, no? ;) no hardware control surface - beside of the real SID sound, you won't notice a big difference between a SID emulation and the HardSID. You are totally focused on your computer (mouse/keyboard), and no generic MIDI controller can ever give you the same human-machine interaction like a real SID synth no support for analog extensions (e.g. analog filters) - seems that this is still one of many unique features of MBSID :) Not that I will be mistaken again (like on my statements about HyperSID some days ago) - I'm writing about my first impressions. There is definitely no "MBSID + the rest of the world" fight, or any need to drag down other projects. Every SID solution has its advantages and disadvantages, and it's good (and a little bit surprising) that still so many developers are working on different approaches. :) Best Regards, Thorsten.

Hi Scube, shortest Pot/Fader conversion latency was always in focus during MIOS development. Basically analog inputs are converted faster than events can be transmitted via MIDI. There is a "dynamic priority" feature, which converts the two last moved faders/pots more often than the others; this improves latency even more. So, you can expect a latency of ca. 1 mS (or 640 uS if the application gets use of the "running status" feature) on the two last moved pots/faders. And this is caused by the transmission time of a MIDI event. If you move more faders the same time, it mainly depends on the number of scanned analog inputs, but even in worst case (64 pots) the latency isn't higher than 12 mS, which you won't really notice, as the transmission of 64 MIDI events takes ca. 64 mS... My tip: open the UC-33E case, and replace the microcontroller board by a MBHP_CORE :) Best Regards, Thorsten.

:)

The perl script mk_midio128_syx.pl converts a MIDIO128 .ini file into a .syx (SysEx) file which can be transfered to the Device via MIDI-OX or any other SysEx Loader -------------------------------------------------------------------------------- Step by Step ~~~~~~~~~~~~ -> customize the .ini file for your needs -> start the script -> transfer the .syx file to your MIDIO128 How to start the script? ~~~~~~~~~~~~~~~~~~~~~~~~ o UNIX Perl comes with the most UNIX systems like Linux, BSD, Solaris, ... - if you own such an OS, just start the script with (example) ./mk_midio128_syx.pl midio128.ini -> the resulting syx file is named "midio128.syx" o DOS/Windows Users should install ActivePerl, which is available at the following site: http://aspn.activestate.com/ASPN/Downloads/ActivePerl/index/ Get the .msi package and follow the installation instructions (Win98 users have to install the Microsoft Windows Install 1.1+, too) To start the script just open a command window and type (i.e.) perl mk_midio128_syx.pl midio128.ini -> the resulting syx file is named "midio128.syx"

It was (and is) just simply love! :) Best Regards, Thorsten.