TK.

Do you know the CE/GS/etc. licenses, which are required for all electronical devices which are sold within the european union? Doing EMC tests in special laboratories isn't that cheap. However, before somebody gets me wrong: I still don't accept your plans before you've really demonstrated your contributions, my statements made yesterday are still valid (http://www.midibox.org/forum/index.php?topic=6216.msg38370#msg38370), and I will propably switch to a better license which matches better with my intentions. A techniqual answer (because this is the main intention of this forum instead of starting flame wars): You propably need another PIC with more ADC channels in order to avoid jitter problems (biggest problem here: all PICs with more than 8 channels have an integrated EUSART, and this peripheral is buggy). You will also notice an increased latency caused by the higher number of conversions to scan all pins, and the memory consumption will be higher (which means: less room for features). Best Regards, Thorsten.

Just write a mail to mike, he has the .brd file Best Regards, Thorsten.

Thats really strange, I know that the schematic is correct (e.g. because Mike made a PCB based on this schematic, and it works fine). Concerning serial/parallel connections: the SDA and SCL pins have to be connected together, I guess that this is still the case on your module? You should be able to disconnect a wire in the chain in order to check, which one is causing the problem? Best Regards, Thorsten.

Yes, but it's hard to estimate, if you are earning more from your business than giving back. Worst case: not you, but maybe the next guy who requests for permission sells hundreds of MIDIboxes over Ebay, but gives zero support. I'm not sure if the community is ready to reply to an increased number of newbie postings like "how to send a certain sysex event" or "I want feature xxx - asap!". So long this project is focused on DIY, the support effort regulates by itself (a little) to a range of people with technical skills. Do you see the point? Best Regards, Thorsten.

Ich habe Michael vor ein paar Wochen ueber die Aenderungen schonmal vorab informiert, er wuerde sie uebernehmen. Allerdings sollten wir warten, bis die ersten Leute die Boards getestet und fuer gut befunden haben. Tim wird zwei Versionen releasen: eine Single und Double Sided - letztere produziert er selbst, die Single Sided ist eher fuer Michaels PCB Prozess geeignet Gruss, Thorsten.

Are you able to write anything into a BankStick? If not, two or more connections of your BankStick board might be swapped. What happens, if a single BankStick is connected -> directly <- to the core module (not using a special board, but maybe only a socket with some wires going to J4) Best Regards, Thorsten.

Great! :) This is no "topics solved" board like the Troubleshooting section, but you will get it in this way: [tt] / / / Solved! \ / \/ [/tt] Best Regards, Thorsten.

Hi, yes the order is correct, but of course it's not ok that the BankSticks are reformatted on every restart. Two questions for my own understanding: is your MIDIbox running with MIOS V1.8? (it provides the important brown-out reset fix) - and how does your MIDIbox behave if only one BankStick is connected? At how many BankSticks do you notice the problem? Best Regards, Thorsten.

Maybe choosing the GPL wasn't a clever idea - my main intention was, that I wanted to give back something to the GNU community as a tribute for the great GNU software I'm using for myself. Of course, it was very clear to me, that this also opened the possibility for everybody to run my software on commercial designs, but at the time I made the decision, it wasn't predictable that the project could ever get such a big acceptance, that even those salesmen become interested. However, you might find reasons to call me a naive guy, but I want to give you following considerations: At any time I can switch to another license like the Creative Commons (see http://creativecommons.org/licenses/by-nc-sa/2.5/) in order to protect my designs against people who are trying to use it in a direction which I don't like. Of course, this means that old software versions released under GPL are still free in the terms of this license. You can make variations and alterations, you could even develop something wonderful based on the old stuff. But such a step would also mean, that you will be prevented from keeping your "products" up-to-date to the main branch - all tries will either lead to a lot of effort at your side, or they will be illegal. Worst case for your venture: if I would switch to another hardware platform. An easy step for DIY people, a financial risk for yourself. Also your reputation won't be the best if the press or your feedback on EBay says "nice product, but sold against the will of the originator, and therefore not supported" I definietly don't want to say, that nobody else but me could realize such projects (far from it - experts should know, that there are flaws which are hard to change without a major redesign - I've learned from it, you not), but I think that I'm allowed to say, that all people who follow the "MIDIbox spirit" will have a big advantage: a great community which is giving a lot of inspirations, which helps to debug and improve the projects, which motivates to continue and to realize things which are just different from commercial stuff you can find on the market. Best Regards, Thorsten.

hm... don't remember - Smash? Best Regards, Thorsten.

Alright! I don't think that you need a new AIN board, just debug the current one. There are some bridges, are they all soldered properly? Note especially the flexible cable connections (yellow thin wires in the mbhp_ainx4.gif file) - You could also add some more solder to the pins of sockets and connectors, maybe this already helps! Best Regards, Thorsten.

Ich vermute, dass sich die SID Daten sogar in Echtzeit berechnen lassen - unter Echtzeit verstehe ich hier bis zum naechsten Timer Tick, der alle 20 mS stattfindet. Die 6502/6510 CPU selbst ist ja ziemlich lahm verglichen zum PIC (die meisten Befehle benoetigten mehrere Zyklen), und die Soundroutinen sind meistens so ausgelegt, dass sie innerhalb weniger "Rasterzeilen" (so hat man damals auf dem C64 Performance gemessen) abgearbeitet werden, so dass noch genuegend "Raster" fuer das eigentliche Spiel uebrigbleiben. Problematisch wird es lediglich bei den Digitunes, deren Sampleausgabe per NMI gesteuert ist. Die verlangen nach wesentlich mehr Performance... aber es gibt vergleichsweise nur wenige .sid Files (zu erkennen an dem _PSID), die mit 4bit Samples arbeiten. Im Grunde ist das nur etwas fuer Galway Fetischisten ;-) Nachdem mir das damals klar wurde, wollte ich Dir eigentlich nochmal eine Mail schreiben, habe es aber irgendwie verpennt. Nunja, so weisst Du nun ueber diesen Weg bescheid :) Gruss, Thorsten.

Hallo Michael, wenn sich der Wert nur nach unten einstellen laesst, hast Du evtl. die Encoder falsch angeschlossen. Das Pinning kann unterschiedlich sein, im Zweifelsfall (sprich: kein Datenblatt verfuegbar), probiere einfach alle drei Kombinationen aus. Die gewuenschten "Defaultwerte" kannst Du dann spaeter abspeichern, indem Du den "Snapshot Button" laenger als 2 Sekunden haelst - geht wie bei einem Autoradio ;-) Zum Code von Jeroen: frage ihn einfach direkt, ob er Dir seine Aenderung zuschicken kann. Soviel ich mitbekommen habe, hat er sie mittlerweile noch optimiert Gruss, Thorsten.

Ich habe 200k Zyklen angegeben (fuer 40 MHz, weil fuer mich das Rechnen mit 48 MHz noch zu ungewohnt ist ;-)) Ja, siddump ist schon ein feines Prograemmchen, und die Sourcen sind ebenfalls verfuegbar. Du musst also kein neues VB Programm aufsetzen, sondern kannst das Format einfach so rausschreiben, wie Du es brauchst (vielleicht laesst es sich ein wenig komprimieren). Oder optional den .c Code assembleroptimiert auf den PIC umsetzen, das sollte auch nicht zu schwierig sein. :) Gruss, Thorsten.

Good news on this topic: it turned out, that the USBD- and +5V line was swapped (in Matthias version, the USB socket is monted on a panel, five cables are wired to MBHP_USB module. This especially explains the strange effect, why windows temporary regognized an unknown USB device when the jumper was disconnected - swapping data with power lines isn't a good idea ;-) However, the cypress chip has survived this torture, the 100 nF cap is doing his job well, MIDI is up&running :) Best Regards, Thorsten.

Some explanations can be found here: http://www.midibox.org/forum/index.php?topic=5758.0, but also in the requests which have already been denied. Note especially the requirement for innovations. Saying "changes to MIOS" already points out, that you don't know how MIOS is working. Based on your descriptions, I don't expect much innovations from your side. I see your point, but I can tell you, that your intention is in contradiction with my goals. Please let me some days to think about an extension of the Rules to make the requirements more clear. Best Regards, Thorsten.

But if your sequencer doesn't send Note Off's, then the notes -> are <- hanging. Thats just the MIDI protocol. If this strange behaviour works with another synth (like the Virus), then it just means, that it works with an algorithm which drops long-hanging notes. MBFM has the same algorithm, but 1) this is not possible with the SID (e.g. due to the envelope bug), and 2) we are talking about a misbehaviour of your sequencer anyhow. In my oppinion there might be a configuration error or something like this in your MPC - you are saying that you do vary the length, and this *must* definitely mean, that once a Note On has been played, there must also be a Note Off after the specified length. Best Regards, Thorsten.

But I've explained my reasons very clearly several times in the forum, I'm just tired of explaining it again and again! The facts that you don't know me, that you don't know the community, that the community doesn't know you, is enough to reject your request. Please tell me a reason, why I should accept your request? Best Regards, Thorsten.

Wagst Du Dich also nun doch an den .sid Player? Ich habe Dir ja mal geschrieben, dass ich das nicht fuer moeglich halte, doch mittlerweile (bzw. nachdem ich mit "siddump" herumgespielt habe), habe ich gelernt, dass die meisten Tunes mit einem Update Cycle von 20 mS - oder auch 200k PIC Zyklen - auskommen. Da ist was drin, und nebenher klappt dann auch noch der Zugriff auf ein MMC Device. Egal ob 6n8 oder 2n2, die meisten Tunes werden nicht akkurat erklingen, da sie fuer den 6581 geschrieben wurden. Gruss, Thorsten.

Moment - does MBSID really crash (boot screen), or does it just skip short notes, or changes the pitch or something like that? Then check the envelope settings! ;-) Best Regards, Thorsten.

No, because if I would explain the reasons, the next unknown guy could take this as inspiration for a better try Best Regards, Thorsten.

Hallo Michael, ja, das funktioniert. Schau mal in das midibox64e.ini File rein (-> mk_syx Script), dort kann man die min- und maxwerte einstellen Gruss, Thorsten.

DENIED

Great work! :) Best Regards, Thorsten.

I cannot believe this - could this be related to your MIDI interface (I remember that there was a problem some time ago... I'm very sure that MIOS based applications don't have MIDI bandwidth problems, even back-to-back Note On/Off won't cause a problem. Just open the SysEx monitor of MIDI-Ox, write "90 30 7f 30 00 31 7f 31 00 32 7f 32 00" in order to send 3 Note On/Off events with maximum speed to MBSID. If the MIDI-Ox trace doesn't show any Note Off event, then it must be a general hardware or driver problem. Pwx: please upload the MIDImon application, which events are displayed? (Unfortunately I still haven't released a new version with prepared setup for 2x20 LCD yet, you need to set the DEFAULT_NUMBER_OF_LINES constant to 2, thereafter recompile the code with MPASM) Best Regards, Thorsten.