audiocommander

Yeah, but they're not good to use. I have two samples and both of them require so much fingerpressure, that you can't follow the rounded form anymore... (you get hot and queeky fingertips ;D ) Maybe they have other ones, too... but I'm not really convinced about these 360° soft-pots samples I got ;) Michael

Me too. No need to blame anyone here for not helping fast enough. :(

You might also check any existing universal 1.5-12V Power Supplies and measure the Voltage with a Multimeter. I found more than one that has about 15V while it should actually have 12V. (I always measure before connecting anything, 'cause I don't trust the printed statement) I got problems using two (fresh) 9V-batteries; never reached the required 15 Volts ??? However, I burned very smoothly with these "factory-pimped" psu's ;D Regards, Michael

hey clearmind! I love your tunes :) unfortunately I can't read any turkish... you got a band or do it all by yourself? great music! ...and Congratulations of your first mb, that's a nice idea with the tape-recorder (I like it when one can see through the case) ;) Michael

yeah, great! :D I'd post some entries too (not next week, but as soon as I got a bit more time, for sure)!

Hi, if you take a look at the midi protocol (http://www.midibox.org/dokuwiki/doku.php?id=midi_specification) you might see what TK said: Not every packet has three bytes, some of them have only two and SystemRealtime is totally different. E.g. if the StatusByte of a 3-byte-package gets lost and the (2nd) DataByte is interpreted as (1st) StatusByte, you might get a PRG-CH instead of a NOTE_ON... that wouldn't be so nice, esp. if you're on stage ;D I can image what might happen if some bytes get lost when transmitting a SysEx Application update :o ...but don't take my opinion for granted, I learned all about MIDI by myself... If I would experiment with wireless MIDI, I'd first try to submit uncritical packets only and use it as an optional method. Otherwise it is really needed to write an additional protocol that somehow wraps the packets and brings the possibility to verify that the received data is the same as the sent data :) Actually this points me to my old PS1-Lightgun, that's waiting to be cannibalized anyway (don't have no 75Hz TV anymore), it would be funny transmitting data by laser or IR that's just received when you point to the right direction 8) In this case it wouldn't hurt if some notes are wrong, but in other than experimental cases, I think it's a lot of work without knowing that it can be processed with acceptable latency. Best, Michael I don't know what you plan about wireless MIDI, but as far as I can remember, you're an experimental midi-boxer, too, right? What about a wireless transmission of a DIN-module? So that you don't actually transmit MIDI, but have a DIN-module connected by RF to the core? :-/ Would save battery energy, too...

Ich bin schon seit ein paar Jahren bei domaingo und für den günstigen Preis (5 bis 15 EUR/Monat) eigentlich sehr zufrieden (im Power-Tarif). Habe (glaube ich) 700 MB. Hat aber ein Script-Timeout (ist aber für die meisten PHP-Anwendungen gut ausreichend), Chat-Server und Freeware-Archive sind Kündigungsgrund und der Support kostet, aber im (kostenlosen) Forum gibt's eigentlich auch immer Hilfe. Und das Admin-Menü ist ziemlich selbsterklärend und recht umfangreich. Nur mit mehreren Domains gibt's wahrscheinlich günstigere Provider :) Grüße, Michael

Here's a topic that might be of interest for you: http://www.midibox.org/forum/index.php?topic=6728.0 Regards, Michael :)

And I learned how to get invoiced with paypal! :) hurray! ;D thanks for your efforts, Slorrin!

Don't miss this topic, where I got some helpful advises and background knowledge about potential problems this method may introduce :-\

whoosh! so near and yet so far from my thoughts (and eyes)!! this core is the third one I've soldered and because I soldered it some time ago (and tested with programs not involving IIC) I've been totally convinced that it's working properly!! And now I see, that I've put this bridge cable in the hole of Mike's Board (there's just a hole with no connections) instead of connecting it to pin#28 (which I did with the other two modules). And because it's the third one, which I soldered some time ago, I focussed only on the speakJet board... :-[ :-[ :-[ (triple embarrasment) Thank you so much for pointing me to the right direction :D Cheers, Michael (btw: that also explains what killed the backlight from my LCD... buhuu, the nice blue one :'( THAT was an expensive and painful learning lesson ::) but I'm a lot more happy that it runs now! NO MORE READY!!! ;D and pps: my breadboard is okay, 've put it to the Wiki!

:o woa, man take care, you ;)

Yeah, that's a nice glitch :) Yesterday, my girlfriend passed the door and I heard her singing: READY - READY - READIYYAAJIII ;D

uups, I totally forgot about MSA, I've been so keen on SCP :-[ Guess that's my problem: always two steps (too far) ahead :-\ I can talk to the Speakjet by RS232 now (was my buggy Mac USB-Serial Adaptor; switched to my old PC) :D yipee ! :D ...but still struggeling with the PIC16: I tried that (only connected to my PC and powered from the IIC line of my core module and removed the MAX232): the PIC16 constantly sends these values: [tt]0x1c 0x1c 0x00 [/tt] followed by a BREAK notification "led-flash" in my current terminal program (RealTerm.exe) And nothing happens when I try to send values (neither via RS232 nor via IIC), The errorneous audio example below matches the timing... (I already tried another PIC16, no difference) Hmmm, this could be a constant resetting of the PiC16 and/or an error in the slave-ID-determination of the IIC-line, or something about the baud-setup, I guess... Measuring the IIC port again shows me, the poles Vd to Vs of the IIC connector are slightly conductive (if I measure Vd with the COM pin of my Multimeter)... but are not conductive from + to GND... As it's the same on the Core Module, I think this is okay ... (god, I hope there's no wire hair hanging somewhere... or even worse: a wrong wired elko... this would be really embarassing :-[ ) Thanks for your input so far - I'll keep you updated! Michael I updated my breadboard plan to reflect the current board-situation: http://www.audiocommander.de/downloads/midibox/mbhp_iic_speakjet_10.board.pdf I also uploaded recordings of this behavior (of course with the SJ mounted): http://www.audiocommander.de/downloads/midibox/SpeakJet_ErrorWithPIC16.mp3 If anyone interested to hear, this is the 'normal' Demo-Mode, with M0 ungrounded, without the PIC :) http://www.audiocommander.de/downloads/midibox/SpeakJet_Demo_Ready.mp3

I don't think so. That would mean a nasty mess if some application would send data without obvious reason (imagine a setup, and once you switch to some sw-instrument a bunch of midi-signals is sent)... nahh, better the other way round :) regards, Michael

The timout might be likely related to your DIN problem, so I first would solve that one. And I don't know about the MB SEQ, but 10 SR means 3 DIN-Modules. here's an obvious suggestion: 10 SRs means the last 2 SRs are not connected, right? Have you connected your buttons in the right order? That means from pin 0 to pin 16 (or whatever) and not from pin 17 to pin 31? If that does not help: Take a break, then look again. You have to know where the error is. So try logically and proceed until you got the point. Swap the DIN-modules to learn if it's the position or any module in particluar, if it's something connected to the module(s) or the chaining of modules(core)... ;) Michael btw: also the DOUT can cause problems, because it uses SR's, too!

Hi gi_joe, it's important for MIOS to know the exact amount of shiftRegisters (SR, each black IC on one D-module means a SR => one DIN connected = 4 ShiftRegisters). If you have only three DINs but the software wants to talk to 16 SRs (ie expects 4 DIN-Modules), this is the very likely reason for you troubles. Put back all 4 DINs and check the inter-connections of the D-modules. Maybe exchange the position of the modules, to see if the problem is somewhere at the core or the chain or if the error is on the respective module. I know it from myself, even if I check everything twice, I then find the soldering error the third time I'm looking :) Cheers, Michael ...and have you soldered the bypass caps on the backside?

Everyone of us misses sometimes obvious links ;) (at least I do ;D )

Thanks TK and Th0mas you for your help and suggestions :) I have made some progress, although no too much :-\ Does that mean, that sending the SerialControlMode commands "[tt]\0[/tt]" (and "[tt]X[/tt]" to exit) as well as "[tt]T[/tt]" for immediate enounciation is not necessary and handled by [tt]IIC_SPEAKJET_TransmitStart(0);[/tt]? I peeked into the PIC16 Firmware for the SpeakJet-Module, but found no hint to any ’\0’ or 0x5C ??? Anyway, it won't work either this nor the other way... I succeeded with Th0mas suggestion to short RX and TX and finally got something coming out when I use a Win-PC (think my USB-Serial device is not working properly on the mac). Athough it's nothing to do with "\0VX" (should enounciate ready), but at least there's coming sound when I press a key :D But once the PIC16 is in it's socket, it enounciates "ready - ii - ready - ii - ee - readyiiiaa" and then starts again, the same loop, 1 word/phoneme per second, sometimes the pattern is changing and specialFX sounds are hearable ??? And I cannot control anything by RS232 if the PIC16 is active. The LED is slightly flickering once the READY is enounciated and I can hear a slight "clicking" (indicates something is sent via RS232) ?? I read in the speakJet forum, that the RST-pin should be tied to +5V with a resistor to avoid constant resetting, but that didn't work either. I got the feeling, that it's more about garbage Tx than a reset issue. But although I can't send anything, I'm receiving an RX-Signal on my PC ('U'), whenever the Chip enounciates something, so one way seems to work :-\ Against all expectations, this is one of the hardest walls I ever knocked my head against, but I've invested so many hours now, I can't waste 'em totally by giving up at this point (although I must admit that I'm very close to :'( ) Cheers, Michael btw: The preliminary MBHP_IIC_SPEAKJET Circuit Plan shows the RS232 Sub D Female Plug from the upper side, while the rest of the plan is shown from above, right? Currently I wired the RS232 plug only by number-references (2:RX, 3:TX, 4:DTR, 5:GND, 6:DSR)...

it can be found in the download section.

there are banksticks! There have been some threads about sampling chips, but AFAIK all were too slow to trigger, so there's currently no need for such huge amounts of storage! By chaining 8 BS, there are up to 512k storage which is indeed quite a lot of bytes. If you want to record waves and do excessive data stuff (view pics/vids?), I think it's much easier using a PC anyway... ;) Cheers, Michael

just try grounding ALL except ONE (just to see if that's the reason; no need to solder, just do it temporarily) - You already wrote that: So it's likely the problem lies within the faders and / or neigboured AINs. What faders do you use? 10k linear? Have you measured the wiring with a Multimeter (Ohm Resistance should grow and shrink when the fader is moved, when you connect the multimeter to the AIN-pin and AIN-GND. regards, Michael

I like the KORG microKONTROL (except for it has no motorized faders). It's small, good quality knbos and faders, has a short keyboard and nice big rubber pads, up to 12 setups... and a very clean, easy to use design. Michael ;)

Sorry to hear that, take your time. We'll be here. Michael.

hmmm, I'm really puzzled. I have massive problems getting the speakJet to function properly with SCP. Here's the thing: - If I plug out the PIC16F, I get a full demo starting with READY, then all phonemes and beebing, whistling and DTMF sounds - If the PIC16F is in it's socket, it just sais READY, which probably means, that the Speakjet is constantly resetted. Can't measure a low-bit on the Reset pin, but I have a quite slow multimeter. Lorin's plan sais, that RCX (pin10 of SJ) should be below 5V, but I get ~5.02V from the PIC16F. - When I remove the PIC16F and ground pin M0 of SJ to GND (M0:GND + M1:5V => normal mode), the demo mode stops, but I cannot send anything via RS232. - If I remove the MAX232EEPE and/or connect to RS232 (PC/Mac) this does not change the situation. Except that I'm hearing some gentle "brrrzzzles" (via line-out with low-pass-filter). I measured the RS232 pins but they seem okay. Here are all the facts: - checked all the connections twice - compared my curcuit again with the plan - compared both with Lorin's circuit plan - checked all solderings - read the speakjet manual at least three times ;D - checked the supply voltage (9V 800mA; tested also with 6V and 12V) - power the speakjet/pic16-board with J2 of the core (although I noticed it's already powered by IIC?) - added resistor to IIC (Sc & Vd) on core - LED on PIC16F is always on (no flickering or anything) - temporarily removed the MAX232EEPE without any different results - measured the voltages of the speakjet-pins, AFAIK OK: 1-9: grounded, 0V 10(VOut): 0~5V, 11(D0/Ready): 5V 12+13(D1+D2): 0V 15(V+): 5V 16(M0): 0V 17+17+19(M1+Reset+RCX): 5V - my application is receiving the notes, shows them on LCD* - implemented errorhandling tells me that the Speakjet IIC transmission functions always return 0 (means no error occurs ??? ), but the thing is: if the PIC 16F is not in its socket, I don't get any errors either, wich is a bit stunning, isn't it? - I can neither send nor retreive any values via (19200 baud) PC (or Mac RS232 via USB connection). Tried different programs (ZTerm, PortTerm, goSerial SerialPortTool), no success :( The serial port can be opened when connected but that's all. But I admit than I'm really confused about these serial access programs like ZTerm. There are so many options besides the baud-rate and the parity/stop-bits, that I don't really know what I should select. I tried lots of them, without success... must be kermit and the pigs from outer-space ;D I also updated my plan, if required: http://www.audiocommander.de/pics/sonst/mbhp_iic_speakjet_08.board.pdf (Edit: see newer postings!) How can I test the PIC16 is working right? I don't hear any baud-configuration sounds as described in the speakjet manual? (I got no warnings nor errors when I programmed the chip) Or is the Quartz damaged? This is the only sensitive part which I had to desolder and solder again? Here is the code I am using: void Init(void) __wparam { // Init vars zsapp.showSplash = 1; zsapp.displayNeedsUpdate = 1; zsapp.error = 0; zs_errorcode = 0; // Init core MIOS_AIN_NumberSet(0); MIOS_AIN_UnMuxed(); MIOS_AIN_DeadbandSet(7); // init interface to MBHP_IIC_SPEAKJET IIC_SPEAKJET_Init(); } void DISPLAY_Tick(void) __wparam { if(zsapp.displayNeedsUpdate) { if(zsapp.showSplash) { MIOS_LCD_Clear(); // display your splash screen here MIOS_LCD_CursorSet(0x00); MIOS_LCD_PrintCString("<<< k.2 _0x1 >>>"); MIOS_LCD_CursorSet(0x40); MIOS_LCD_PrintCString("mbhpIIC_speakjet"); // delay Display Refresh MIOS_LCD_MessageStart(0xFF); // show for 2 seconds zsapp.showSplash = 0; } else { if(zsapp.error) { // an error occured! MIOS_LCD_Clear(); MIOS_LCD_CursorSet(0x00); MIOS_LCD_PrintCString("**** ERROR ****"); MIOS_LCD_CursorSet(0x40); MIOS_LCD_PrintCString(" code# "); MIOS_LCD_CursorSet(0x40 + 7); MIOS_LCD_PrintBCD3(zs_errorcode); MIOS_LCD_PrintChar(' '); MIOS_LCD_MessageStart(0xFF); // show for 2 seconds zsapp.error = 0; } else { // display your content here // show last forwarded message to IIC MIOS_LCD_CursorSet(0x40 + 5); MIOS_LCD_PrintBCD3(iic_lastValue); // update done zsapp.displayNeedsUpdate = 0; } } } } void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { // Example which just forwards incoming Note Events to the SpeakJet: switch(evnt0) { case MIDI_NOTE_ON: // NOTE_ON, CH1: 0x90 zsapp.error = IIC_SPEAKJET_TransmitStart(0); if(zsapp.error) { zs_errorcode = 1; } // set speakjet to serial control mode zsapp.error = IIC_SPEAKJET_TransmitByte('\\'); if(zsapp.error) { zs_errorcode = 2; } zsapp.error = IIC_SPEAKJET_TransmitByte('0'); // 0 for all speakjets, 1-7 for addressable! if(zsapp.error) { zs_errorcode = 3; } // tranmit buffer zsapp.error = IIC_SPEAKJET_TransmitByte(evnt1 | 0x80); // | 0x80 => soundcodes 128..254 if(zsapp.error) { zs_errorcode = 4; } // start immediate enunciation of buffer zsapp.error = IIC_SPEAKJET_TransmitByte('T'); if(zsapp.error) { zs_errorcode = 5; } // put speakjet out of serial control mode zsapp.error = IIC_SPEAKJET_TransmitByte('X'); if(zsapp.error) { zs_errorcode = 6; } IIC_SPEAKJET_TransmitStop(); // store last value iic_lastValue = evnt1; break; } // update display zsapp.displayNeedsUpdate = 1; } I ran totally out of options at this point, I haven't even an idea how to bug down the area of the error; any hint is really appreciated!!! And herewith I'm volunteering for any documentation jobs if I get this little intractable thing going ;D I'm sorry for this horrible long posting :-\ Thanks for your time! Michael *another thing I have to mention, is that my LCD-Display got very (very) dark over the last weeks. I switched Cores and LCDs and it's the LCD; think the background illumination is dying. I measured the voltages on the LCD-pins of the core, but they all seem normal to me (5V max, exact 5V on B-/B+ and Vs/Vd).