TK.

Are you already using the new app_lcd/clcd_multi driver I gave doc? ;) Best Regards, Thorsten.

Does the player send an "All Notes Off" CC? (CC#123) - MIDIO128 could be enhanced to parse this CC and to turn off all outputs once received Best Regards, Thorsten.

In distance to IIC, SPI doesn't allow to stretch a data transfer request, accordingly the SPI slave has to handle the request immediately during a block transfer to avoid data loss. An handshaking to sync the master with the slave can only take place at the beginning of a block transfer. Since SD is interfaced via SPI as well, the resulting overall bandwidth will be (much) lower than the speed which could be achieved on a direct connection. And it would probably be lower than using the more reliable IIC protocol. Only elegant solution I see for a multi-processor setup: searching for a ready-made open source solution which is running on a faster microcontroller. The microcontroller should be faster than the PIC to avoid performance loss. Once such a project has been found, let's compare the costs ;) Best Regards, Thorsten.

Thank you, the list of your favourite features is a really useful input for me! :) Best Regards, Thorsten.

I would propose to join the GM5 order, it's the best solution, especially better than COM->USB chips (read the thread for details) You won't find firewire based MIDI interfaces because the isochronous protocol makes it unusable for live playing. Best Regards, Thorsten.

I had the idea to use a PIC18F4550 to bridge the SD card to USB and IIC, but I skipped it because of the reduced flexibility, and the slow IIC transfer speed. I also think, that getting such a system stable and foolproven would cost me even more effort. Best Regards, Thorsten.

Polyphonic recording on a single track would be easier to realize than multi-track recording; I planned to go this way Unfortunately doesn't comply with the handshaking concept I used for chain mode (see also comments about handshaking in seq_core.inc), I would have to think about a new solution, and overwork it completely. Would this really be worth the effort? I know what you mean - In such situations, I activate the "sync to measure" function in the clock divider page, until the track rolls over. Thereafter I deactivate this function again. I could also provide an additional "push-button solution", but how should it be called so that nobody overlooks this feature? I mean: you already overlooked the possibilities of "sync-to-measure", no? ;) Second one: "manual trigger" page Btw.: you know, that my ToDo list works like a FILO? ;) [tt] +---------+---------+---------+---------+---------+---------+........ New User ----> | Request | Request | Request | Request | Request | Request | Requ... request +---------+---------+---------+---------+---------+---------+........ <-------------- will be implemented --------------> <--------- --> somewhere burried in the forum [/tt] Best Regards, Thorsten.

Yes, I know about the imperfections in live record mode - I also would like to have it more intuitive I'm thinking about a possible solution since months, but haven't found a good - feasible and completely working - one. I would prefer an absolute delay which works independent from the BPM - but there are no free HW resources (especially because Timer0 will be used for the Tap Tempo function in future) A delay depending on the microticks (96th's) would lead to a different feeling on slower BPM rates. I tried this some time ago, but it was more confusing than today - and the code looked really uggly and error prone. E.g. I wasn't able to properly record on chained tracks anymore! :( See my long explanation in the 808 forum: http://www.eight-oh-eight.org/phpbb2/viewtopic.php?t=169 Summary: there is an alternative firmware available which works perfectly for drum patterns. :) There are already two different chord modes, what is missing exactly? not sure if I will ever implement this... too many requests, not enough sparetime. However, some more ideas regarding CC automation can be found via search function Best Regards, Thorsten.

To give you some numbers: reading a 512 byte sector takes ca. 3 mS, writing a 512 byte sector ca. 4 mS For comparison to an IIC EEPROM: 512 byte read ca. 11 mS, 512 byte write ca. 100 mS Flash memory consumption of the driver: ca. 600 bytes of course, it would be better - but who is skillfull enough to implement such a tool? It could be difficult to get raw data access via a common SD card reader. However, writing/reading sectors of the card via SysEx would work as usual, we are speaking about a more comfortable, and especially faster solution (if you want to read/write data from any computer w/ a cheapo SD card reader). I think, that it wouldn't be so difficult to search in the root directory for a single file which holds the complete data (e.g. "SIDBANKS.DAT"), and to go through the FAT to find out the corresponding clusters/sectors. So long the used clusters are cached in a buffer, it wouldn't decrease the access speed. It's something which cannot be realized in one day, but maybe in two until it will work ;) Best Regards, Thorsten.

Haha ;) A PIC is too slow to take advantage of the bandwidth already provided by MMC/SD cards, so it doesn't really make sense to consider alternative solutions. Isn't it much more difficult to interface a CF card to a microcontroller? Best Regards, Thorsten.

It's much too early to prepare SD card support for applications, because I'm still in the evaluation phase. Meanwhile I've written routines to read/write sectors, but it's still unclear to me, if FAT support is feasible for applications like MBSID, because it requires a lot of additional code. Maybe with some dirty programming tricks it will be possible... Means in other words: it's a piece of cake to use a SD card as BankStick replacement, but once you want to transfer files to/from a computer as well (-> FAT support), a solution which works flexible enough probably gets too complex. Some useful resources I found: FAT16 driver by Roland Riegel: http://www.roland-riegel.de/sd-reader/ FAT in a nutshell: http://home.teleport.com/~brainy/fat16.htm A very geeky SD socket replacement by Rob Wentworth: http://uanr.com/sdfloppy/ The last side confirms, that data input and output can easily be merged to a single line, which means, that only 3 GPIO pins are required (one dedicated pin for CS#, two pins for clock and data IO). The upcoming sdcard driver will allow to freely assign the pins to GPIOs I won't have the time to continue the evaluation in the next two weeks, but you can be sure that SD cards will be supported in future :) (I will open a new thread later). A nice demonstration project would be a MIDI file player, but it could also be a MIDI stream recorder ;) Best Regards, Thorsten.

I guess, that you missed the pin list: http://www.ucapps.de/mios/mios_pin_list.txt I would propose to start with pin RC4, RC5, RD4 (I guess, that you are not using touch sensors) In order to assign these pins, add following lines to the Makefile: [tt] # include MAX72xx driver MAX72XX_DEFINES += -DMAX72XX_CHAINLENGTH=1 MAX72XX_DEFINES += -DMAX72XX_LAT_CS=LATC -DMAX72XX_TRIS_CS=TRISC -DMAX72XX_PIN_CS=4 MAX72XX_DEFINES += -DMAX72XX_LAT_SCLK=LATC -DMAX72XX_TRIS_SCLK=TRISC -DMAX72XX_PIN_SCLK=5 MAX72XX_DEFINES += -DMAX72XX_LAT_DIN=LATD -DMAX72XX_TRIS_DIN=TRISD -DMAX72XX_PIN_DIN=4 include $(MIOS_PATH)/modules/max72xx/max72xx.mk [/tt] LATx and TRISx are described in the PIC datasheet. For you it's probably sufficient to know, that they control the pin output value and tristate driver Btw.: this is how you can add the driver into a C application. I assume that you will do the first experiments in C to save time. I'm currently a bit too lazy to describe the differences between defining constants in assembly (which would be done in main.inc) and in C (where it is done in the makefile) However, the AOUT driver is a nice example which shows the differences (e.g., have a look into the most recent MBSID/MBFM/MBSEQ or MBCV code) All the documentation issues are btw. a big blocking point for me, which prevents me from releasing the programming platform. I fear, all the different possibilities makes it too complicated. :( Best Regards, Thorsten.

Hi Mike, no problem, I will add this. Any other suggestions for new event modes? Are you using any "progression parameter"? Chaining doesn't work properly together with these functions. Yes, I think I should add the possibility to sync to any measure between 1..128 steps - it would also solve other issues (e.g. synchronized pattern change after 4 bars) This will be a global parameter for all tracks. Best Regards, Thorsten.

Ok, it's clear now - only the bus routing is time critical, but this should work fine with the 74HC devices :) Using discrete devices for the so called "glue logic" is the best way to go for such a project, because other solutions require special equipment (e.g. an EPROM programmer), which makes DIYing more expensive. Best Regards, Thorsten.

Great idea! :) Do you know the maximum bus frequency? I fear, that a PIC cannot handle it... It sounds like a typical FPGA project. There are cheap evaluation boards available with huge external SRAMs. You could also interface a CF or SD card in addition + the original PCM card (mostly there are hundreds of IOs), but it would require some HDL skills. However, maybe an ideal project to get into this topic :) Best Regards, Thorsten.

Controlling a MAX7221 via DOUT interface requires a lot of programming skills, because you need to know, how to write a "sequential state machine" which controls the register write accesses on each SRIO update cycle. PWM: see this article However, I think, that the application has enough spare pins to drive the chip via GPIOs (only the CS# line should be a dedicated output, all others can be shared). The README describes, how to adapt the pins - it's easy! Best Regards, Thorsten.

If equipment doesn't matter, you could use a PLA (e.g. years ago I used GALs for such purposes) Or if size/PCB area doesn't matter: just use a memory, e.g. an EPROM with parallel interface, and program the complete logic table into it. Best Regards, Thorsten.

Manual Optimisation: http://de.wikipedia.org/wiki/Karnaugh-Veitch-Diagramm Experts would quickly write the terms in Verilog or VHDL, and push the "synthesis" button ;) Best Regards, Thorsten.

Addendum: with MB64E you can achieve this by assigning buttons to the group switching functions as documented here: http://svnmios.midibox.org/trunk/apps/controllers/midibox64e/doc/midibox64e_sfb_table.txt 128 parameters are available per bank, which means: if you are using 16 rotary encoders, they are splitted over 8 groups. LEDs: one DOUT has to be mapped to value "9": # 9 Selected Group (1 of 8 ) so that 1 of 8 LEDs is lit depending on the selected group. see also the midibox64e.ini file of the mk_syx package Best Regards, Thorsten.

If you are doing code modifications which should be re-used in future by other people, please start with the most recent code which is available in the MIOS repository Otherwise, changes I already did for the blm module have to be redone for your module - this is very time consuming :-( Best Regards, Thorsten.

MIDIbox MM is a C based application, and it supports LED rings: http://svnmios.midibox.org/trunk/apps/controllers/midibox_mm/src/mm_vpot.c Best Regards, Thorsten.

D7 should stay at 5V, so it seems to be a short circuit between CS# and D7 Best Regards, Thorsten.

Yes, the screws are doing the trick. The construction itself is stable, I'm still using my original hardware since many years. But maybe I should highlight, that I mostly got bad marks in handicrafts @ school ;) Best Regards, Thorsten.

No, this works fine (e.g., the blm module is also used by the MBSEQ V3 application) Best Regards, Thorsten.

I moved this topic, because I fear that the endless "but you can do this with linux as well" discussion could start in a forum section, which mainly intended for organizing bulk orders (people could loose the oversight) I was using Linux for more than 13 years, mainly for programming and internet stuff; in parallel I used Windows for doing music stuff (Logic Audio, Reaktor). There was always the issue, that I had to switch between the operating systems, e.g. if I wanted to try out some new MIDIbox code with a real application, and back to Linux if I wanted to reply on an email... after a friend demonstrated MacOS, it was clear to me, that no other OS supports my personal requirements so well :) Best Regards, Thorsten.