seppoman

Hi, 4V sind natürlich zu wenig. Die kommen auch, wenn Du vom 14-V Kabel (unangeschlossen) auf die Masse der 5V-Versorgung mißt? Wenn ja, würde ich sagen Du hast in der kleinen Otimized-Schaltung irgendwas falsch. 4V würden sich z.B. ergeben, wenn nicht 5V und 9V addiert, sondern 5V von 9V abgezogen wird (nur so ne Idee). Kannst Du von der Schaltung evtl. Fotos (oben und unten) machen? Seppoman

Hi Rio, Machs doch einfach so wie´s in der Anleitung steht, Thorsten hat sich schon was dabei gedacht? Der Core wird direkt mit 5 V versorgt, deshalb braucht man keinen Regulator. Und vor allen Dingen läuft der Core mit 7805 so überhaupt nicht, da der Regulator immer 1,5 bis 2 V mehr braucht als er rausgibt. Wenn Du also an einen 5V-Regulator 5V Eingangs-Spannung hängst, kann er nicht arbeiten und hinten kommt deshalb keine sinnvolle Spannung raus. Hast Du denn MIOS und die MB_SID-Applikation schon drauf? Solange der Core nicht arbeitet, wird es nicht möglich gewesen sein, die Firmware einzuspielen. Dann ist klar, warum man nichts hört. Also 7805 raus, Brücke von Pin 1 auf 3 löten. Die SID-Platine unverändert lassen. Die Masse bekommt die SID-Platine übrigens über das achtpolige Verbindungskabel, genauso wie ihre 5V-Versorgung. Wenn Du ihren Schaltplan anschaust, wirst Du sehen, daß der 5V-Ground und der (14V)-Ground sowieso zusammenhängen. Deshalb ist bei der Optimized-Schaltung keine zusätzliche Masse angeschlossen, wodurch Brummschleifen vermieden werden. Viele Grüße, Seppoman

Hi Thorsten, thanks a lot for your hint :) Today I experimented with the SM example1, and it works like a charm even with the standard 1ms setting and 1 SR config. I set the timing to 2 ms and changed the surrounding cables for shielded ones, so I think there won´t be any bad surprises even in RF intensive surroundings ;D Thanks again, Seppoman

Hi Davo, I suppose I could have found some suitable cable, but now everything is connected, taped together etc. To change the cables at the edge is a few hours, but to rewire everything is not possible in the next few days - I´d have to build nearly the whole thing from scratch again.... This is a part of a university project which will be presented this friday to the press and next week on the PopKomm fair in Berlin, so I´ve got quite limited time to get it running. If there´s no way to make it more stable through timing and edge rewiring (see above), even splitting the area into parts with more than one Core would be a faster solution than complete rewiring. Seppoman

Let me first post a few pictures so you know what I´m talking :) The squares are connected seperately because I didn´t want the diodes and the solder joints to be stepped on. I chose transformator wire because the wire has to be thin and must stand being walked on, which is not the case with cheap shielded audio/headphone wire. Apart from these considerations it would be A LOT of work to exchange these. But I will try to replace at least the wires along the edge by shielded ones. Anyway, the aluminium is of course also a BIG antenna - it´s around 20 quare meters foil netto. And around this floor there will be a lot of electronic devices - amps, D/A converters, computers etc. so I already fear what will happen when the floor is in the actual setup... So would it be possible to set the application to a more relaxed timing to reduce crosstalk sensibility? Hopping around on a floor it´s not possible to play a fast melody precisely anyway, and the floor won´t be used to trigger notes, so I´d have no problem with e.g. 5-10 ms latency. Is there a way to achieve reduced crosstalk sensibility by simply initializing the timer to a different rate? Or should I better use the SM example 1? Thanks a lot for your input :) Seppoman

Hi all, as a new university project i´ve built a sensor floor. it´s 3x4 meters, 6x8 diode matrix "buttons" large. the lower part is built from separate areas of aluminium foil, each row connected via diodes at the edge. Above a separating layer (some rubber-like net) rows of alu foil are glued to the carpet. This construction is connected to a core / DinX1 /DoutX1 board using the SM_example2 application. Now to the problem: As long as only one "button" is closed, everything works, also when the second "button" is in the same row or line as the first one. But when a second button is pressed e.g. like x o o o x o so that row and line are totally independent, the application sends a fast tremolo alternating both respective notes. This happens with some (but not all) other combinations that are not in the same row or line. I hope the description is understandable - it´s difficult to describe because I don´t find a real logic in when this happens and when not. I did fear that problems would arise because of the long cable lengths and the large "capacitor-like" button fields. But as single actions work alright, I suppose it has to be something not directly related to cable lengths. Is there some configuration thing in the sm driver I missed that could be responsible, or should I add e.g. some caps somewhere that could stabilize this rather strange system? Any help is greatly appreciated - this thing has to work next week or I´ll have a big problem :o Seppoman edit: I made more tests today - the first three rows don´t show the problem. It starts from between row 3 and 4, i.e. when the cable lengths become larger. So if no other solution comes up, I could split the area and connect it to 3-4 cores. But this would mean more wires, more electronics and MIDI mergers :-\

Sure - how would the PICs know what to to without software? It´s all written on the ucapps.de pages. Especially notice the section about Device IDs on http://www.ucapps.de/midibox_sid_csB.html Seppoman

Hi, a single 9V supply is fine. Use a display without backlight! The backlight of most displays take 100 up to 500 mA, so the batteries won´t last long. But 6 batteries won´t work very good. Rechargeable batteries normally have about 1.2 or 1.3 Volts per cell. 1.2x6 is only 7.2 V which is not enough. But even if you use alkaline batteries, their voltage will drop lower long before they´re empty. I´d suggest using a supply of around 12 V and use the regulator cirquits on the boards to get 9 and 5 V. So if you´re going to use alkalines, take 8 cells and if you want to use accus, take 9 or 10 cells. Seppoman

Hi, "VIEL leiser" ist absolut normal (wie schon weiter oben beschrieben). Wenn´s zu sehr nervt, ein Noise Gate oder einen 8580 benutzen. Nur in Acids MP3 ist der "Nachklang" ja fast genausolaut wie das Nutzsignal, und das ist definitiv nicht normal. Seppoman

Hi, das klingt wirklich komisch, sooo laut sollte das nicht sein. Evtl. könnte der SID selbst ne Macke haben. Das klingt so, wie wenn einer der drei Oszillatoren einfach anbleibt. Du könntest das mal testen bei einem Nicht-Wavetable-Sound z.B. dem Init Patch, indem Du jeweils einen der drei deaktivierst. Wenn bei einem bestimmten Oszillator das Problem verschwindet, liegts wohl am SID. Ich hatte mal einen, bei dem der dritte Oszillator immer nur kurz anging, während die anderen beiden normal ausklangen. Ansonsten könnte theoretisch noch was an der Daten-Verbindung zwischen Core und SID bzw. auf der SID-Platine defekt sein, evtl. nochmal alles zwischen Core und dem SID-Chip mit dem Multimeter durchpiepen. Ich denke aber, daß es eher am Chip selbst liegt. Seppoman

Hallo, ich nehme mal an, daß Du einen 6581 hast. Das ist absolut normal. Der Chip hat einige Macken, die teils aber auch das Interessante am Sound ausmachen, und dieses Hintergrundgeeiere und das laute Knacken beim Umschalten gehört dazu. Wenns Dich zu sehr stört, benutze ein Noise Gate. Der 8580 dat diese Probleme weniger - besonders das Hintergrundgeräusch ist wesentlich leiser. Ich finde ihn aber auch weniger "rotzig" - aber viele im Forum finden den 8580 besser. Geschmackssache :) Seppoman

Surely it is possible. With PD (and MAX/MSP which is more or less the same) you can do almost everything you can imagine. E.g. the game for my Midibox Sofa is programmed in PD. There are great collections of addon libraries ("externals") you can use. E.g. GEM is for graphics and video (OpenGL based) and PMPD is a physical modelling library, it´s used in the game for creating gravitation and physical reflection. If you know what you want and some of the mathematical background, the possibilities of this system are endless - wierd sound effects, convolution reverb, wave field synthesis, any kind of effects or synthesis methods, creating and modifying video depending on midi or audio input etc. FYI, in winter I started creating a MBSID-compatible VSTi with MAX/MSP. When it´s finished, I´ll release it as PD, so people could try out the synthesis before building the real thing or add extra voices for sequencing when needed. At the moment, the sound engine already has the same features, only the WT sequencer is missing and it´s not yet patch/sysex compatible. But don´t wait for it every day - my time is quite limited at the moment and it will surely take another few months to be finished. And of course it´s only a digital emulation, so the imperfections and thereby some of the charme of the original SID will be missing... Seppoman

Hi, Sure, on presentation we´ll be using either a plasma TV or a beamer for the real feeling. Some sound effects and a bit better graphics will also be added. And there´s no real "game flow" up to now, so perhaps more levels (e.g. with obstacles), some bonus point system etc. is needed :) I´m not sure what you mean by "proportional spacing to the two hands"? If you mean the sofa is a bit narrow, you´re right - but perhaps it´ll help some relationships to be founded ;) Well, the single faders of course work linear. The value range of the outer bottom sensors is a bit smaller and the middle ones have slight "crosstalk" problems. I´m thinking of splitting the cloth between the two seats and adding a wooden hard border there. This would probably solve both issues, but also look a bit strange. Perhaps it´s easier to find some algorithm and do this in software. At the moment, we´re just calculating a delta value between left and right and will probably do some kind of "calibration phase" before the game starts to put the hand to mid position when there´s no movement. We´ll have to record and analyse what happens to the second seat when one person moves and the other doesn´t to find a way to minimize crosstalk. But it´s also not that important to get perfectly accurate values. The game already reacts quite well to the movements, and as the seats are near, your neighbour affects your position anyway. In musical context, precision is also not so important. You won´t be able to play the Flight of the Bumblebee on a sofa anyway and for e.g. filters or abstract parameters like "complexity of an arrangement" the precision is good enough. Seppoman 8)

Hey guys, thanks a lot for all your comments :) As the "Pong-Like Game" is quite functional by now (though not finished yet), I´ve made a small video clip of the sofa being used. Playing the game definitely makes one look silly ;) - Any musical application is still to come. Here´s the link: http://www.seppoman.de/sofa/Sofafilm.mov Seppoman 8)

Hi Thorsten, OK, this is where I come in :) I´m sending you the driver source code right now. I think I didn´t define any new variables or use any variables/registers that are not used by the standard CLCD driver, but I don´t have too much programming experience with Assembler, so perhaps you can see something I´m not aware of. I don´t have a clue what´s the problem here. My own box with the VFD is ripped into pieces at the moment (needed core modules for other projects and it will be redesigned anyway), so I can´t verify if this problem occurs only with newer versions of MIOS or MBSID. The driver definitely worked with MIOS 1.6 and MBSID 1.6 without any BankStick related problems. Kind regards, Seppoman

Hi, 24LC64 geht nicht, das ist zu klein. Bei Reichelt gibt es geeignete EEProms unter der Bezeichnung ST 24C256 bzw. ST 24C512. Die ST-Versionen haben den Nachteil, daß sie keine Möglichkeit einer Bank ID haben, d.h. man kann nicht mehrere gleichzeitig an die MidiBox hängen. bei der 512er Variante hast Du allerdings sowieso schon zwei Bänke in einem Chip. Ansonsten verschickt Reichelt wohl in letzter Zeit unter diesen Bestellnummern sowieso keine Chips von ST sondern von Atmel, und diese haben immerhin 4 konfigurierbare IDs. Wenn man 4 von diesen 512ern einbaut, hat man z.B. bei der MBSID oder FM 128x8 Presets, das sollte genug sein :) Wozu? Die Banksticks funktionieren problemlos, sind günstig und einfach herzustellen. SD-Card hätte nur Sinn, wenn darauf ein FAT-Dateisystem existiert (zwecks Backups oder so). Das wäre aber ohne Softwareänderung nicht der Fall, und eine Umstellung würde Dutzende (Hunderte?) Leute dazu zwingen, bei einem Softwareupgrade ihrer existierenden MB auch auf SD umzustellen. Insofern sehe ich dafür keinen Grund (außer, daß es vielleicht "cooler" ist). Viele Grüße Seppoman

Hi Sebastian, of course it´s more elegant to have only the lines in the table that are relevant, but If you just want to have the 10 menu encoders running for now, you don´t need to change anything in the cs_menu_enc.inc. my changes there are just because of the 2 instead of 3 layers. Just modify the original table, nothing else as a first step. The cs_menu_inc_table is a table where the lines have to be in a defined order if you don´t change anything else. So for only menu encoder function it would be the most simple solution to use the standard firmware and just replace the first five entries of the OSC and ENV entries with the Change_menu... functions. If the display positions are then still rotated, it could perhaps be a small bug in the 1.7 firmware. the P6...P10 functions are not used in Thorsten´s CS so perhaps some small error slipped in unnoticed. So first try this with the standard firmware and only change the P1..P5 in the Env Assign layer to P6..P10. Then we know if it´s Thorsten´s or your bug (or mine if you used anything else from me so far ;) ) Offsets: Do you mean the numbers in the CS_MENU_ENC routines or the offset column in the table? In the table, there are just definitions about which segment of the menu should be shown. When you set Offset 0x02, the first visible value will be the third one of a certain menu, and Cursor pos selects which of the visible values is selected. For the change_menu_Px function, these are always 0 because you don´t want the cursor to jump away if you change a value on the display :) Seppoman

Hi Sebastian, have a look at the firmware I sent you :) The encoder functions are defined in cs_menu_enc_table.inc - there you can find the following section: ;; Env "Assign2" Layer ;; Function name parameter menu offset cursor pos CSENC_ENTRY CS_MENU_ENC_CHANGE_MENU_P6, 0x00, 0x00, 0x00, 0x00 CSENC_ENTRY CS_MENU_ENC_CHANGE_MENU_P7, 0x00, 0x00, 0x00, 0x00 CSENC_ENTRY CS_MENU_ENC_CHANGE_MENU_P8, 0x00, 0x00, 0x00, 0x00 CSENC_ENTRY CS_MENU_ENC_CHANGE_MENU_P9, 0x00, 0x00, 0x00, 0x00 CSENC_ENTRY CS_MENU_ENC_CHANGE_MENU_P10, 0x00, 0x00, 0x00, 0x00 ;; Env "Fun" Layer ;; Function name parameter menu offset cursor pos CSENC_ENTRY CS_MENU_ENC_CHANGE_SYS, CS_SID_WAVETABLE_RATE, CS_MENU_WT, 0x00, 0x05 ; WT Speed CSENC_ENTRY CS_MENU_ENC_CHANGE_LFO, CS_SID_LFOx_DEPTH, CS_MENU_LFO, 0x00, 0x03 ; LFO Amount CSENC_ENTRY CS_MENU_ENC_CHANGE_LFO, CS_SID_LFOx_RATE, CS_MENU_LFO, 0x00, 0x02 ; LFO Speed CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_ATTACK, CS_MENU_OSC, 0x03, 0x04 ; VCA Attack CSENC_ENTRY CS_MENU_ENC_CHANGE_OSC, CS_SID_VOICEx_RELEASE, CS_MENU_OSC, 0x03, 0x07 ; VCA Release I "misused" the original "Env" Encoder section for the second 5 encoders. First there´s the 6-10 menu values, then there´s the second half of the "Fun layer". Both the OSC enoders and the ENV encoders are switched at the same time by the Fun Layer button. I reduced the layers of both to 2. If you want to have more layers, you could add at least one more by simply removing some of my modifications. The switching of the two layers is done in cs_menu_buttons.inc with the following routine: CS_MENU_BUTTON_Osc_Ctrl ;; do nothing if button has been depressed IFSET MIOS_PARAMETER2, 0, return ;; increment OSC Ctrl parameter (0x00-0x01) incf CS_MENU_SELECTED_OSC_CTRL, F movlw 0x01+1 IFGEQ CS_MENU_SELECTED_OSC_CTRL, ACCESS, clrf CS_MENU_SELECTED_OSC_CTRL ;; increment ENV Ctrl parameter (0x00-0x01) incf CS_MENU_SELECTED_ENV_CTRL, F movlw 0x01+1 IFGEQ CS_MENU_SELECTED_ENV_CTRL, ACCESS, clrf CS_MENU_SELECTED_ENV_CTRL goto CS_MENU_LED_Update Hope this helps :) Seppoman

Great, congratulations :) Seppoman

Hi, The SID can´t be the reason as the connection is one-way, so the core doesn´t even know if a SID is there. Just to be sure, first try to get the core running without the MBSID module connected. Damaged PICs are also quite uncommon as long as you didn´t e.g. put it in the socket the wrong way. First double check the MIDI out connection. If the PIC has the bootloader, it has to send something as long as the voltages are right and there´s no problem with the quartz. Check if the MIDI out data wires are connected the right way and if there´s connection to the corresponding pins of the PIC. Also check that Midi-Ox has any input filtering disabled. Seppoman

Hi Jurbo, I didn´t really find out. I once eBayed a huge package with 2 C64s, 4 floppies and a lot of half-broken joysticks and one broken dot matrix printer. The mail man breathed very hard ;) Two drives were ok, one broken, and this one had no power supply. I tried it with a 1541-II PSU because it had the same connector and it didn´t work. But I don´t know if the Commodore PSU is suitable. Anyway, I think this way it´s soul will live on :) Thanks - it gave me quite a headache to get all the connections right, two very long nights of soldering and thinking. But I think it´s also quite rewarding to do this by hand one time, because you can more physically learn to understand how everything is interconnected and how it works. But I won´t do this again, one time is enough ;) Seppoman

Hi guys, Thanks for your comments :) Actually there´s not so much room inside for additions - above the board there´s only about 15 mm of "usable air" and below the display about the same. The case is just 4 cm high, way smaller than a 1541 floppy. If there would be a board below any CS items, everything would get very crowded inside. A second SID is not needed for live performance in my opinion, and the CS can´t ever be the full version on this size, so this box is not for creating sounds via CS but only for using them anyway. I briefly thought about at least adding the filter section of the CS, but the encoders/buttons/LEDs would need another DIN_X1 and need to be placed on the free front portion of the case. But a good workaround for live use is to route the filter cutoff to the MOD-wheel of the keyboard. I also wanted to preserve a bit of the floppy disk look, and a disk drive with 30 crowded knobs standing out of the top would just not look nice. I´m a friend of clear simple designs, as you can also see on the Brat 1000 :) Anyway, the "Brat. 3000" is still in the queue, It will have a similar surface as the 1000, but with 4 SIDs, a huge VFD display, and I´m thinking of adding a Boss SE-50 effects unit and perhaps a simple 4 channel mixer, so this will be the luxury version the 50 doesn´t need to be :) I´m just sending Thorsten a mail with fotos of a very special MB64 and a MidiMon, so more pictures to come :) Seppoman

Hi, ich hab mich vor einiger Zeit mal schlau gemacht wegen Zoll. Ist zwar etwas kompliziert rauszufinden - erstmal irgendwelche Warengruppennummern herausfinden, dann mit diesen auf einer Seite der EU suchen usw... - aber jedenfalls gibt es sowohl aus USA als auch aus Asien (ich hab wegen Microchip mal Thailand nachgeschaut) von Seite der EU keine Einfuhrzölle auf elektronische Bauelemente. Die werden nämlich anders behandelt als komplette Geräte. Ob die USA irgendwelche Ausfuhrzölle erhebt, weiß ich allerdings nicht. Seppoman

Hallo, gibt es eigentlich neue Pläne/Termine bzgl. des Treffens? Ich fänd´s immer noch nett, wenn so ein Treffen zum Fachsimpeln, gegenseitigen Boxen-Präsentation stattfinden würde, und wäre auf jeden Fall dabei. :) Seppoman

Hi Alex, the Out of the Core is serial regardless of Midi or LTC option, so you would need to build some serial/parallel converter, and probably write your own Windows driver. Way too much effort. If you need a cheap parallel Midi interface I can recommend the old MotU product line. I´ve got a MotU Pocket Express (2 In, 2 Out, SMPTE) from eBay for 20 Euros. Lately I exchanged it for a Micro Express (4 In, 6 Out) which cost me 35 Euros. Both have Win2k/XP drivers and a parallel port. Seppoman