audiocommander

So what happens if you set the DEFAULT_PATCHMODE to 1 ?

??? => we're talking of the mb64, right? where the hell are you looking? ;D regards, Michael (good you moved it, btw ;) )

but the problem with serial (RS232) connections and PCs is, that they're operated with 12 V. And USB runs with 5 V. So if you got a cheesy cheap USB->serial adapter (like me) that won't get 12 V but only 7.x V, it won't work. And until I got the idea of measuring the Voltage, it took a loooong, looooong time :-\ I'd definitely try USB->parallel, 'cause the Burner Module works with an external PowerSupply (15V) ... though I never tried a USB->parallel adapter, just my 2c's ;) Cheers, Michael

hey, that's cool :) I have the impression that the number of user projects has grown dramatically in the last time ?! I like that very much. These links are a great idea! btw I'm working very hard to get a stable second version of the speakjet up. Rio developed a keyboard add-on and worked on the synth module while I added a cool distance sensor matrix. Guess this will be a very promising project... Afterwards I'll focus on a Sensorizer update again with a bunch of new features... nearly ready, too 8) (and just a sidenote: the speakjet link is wrong, should be http://www.midibox.org/dokuwiki/doku.php?id=midibox_speakjet ) Cheers! Michael

Hi Paul, welcome to the forums :) maybe it's simple and you just have to add [tt]PATH=/usr/local/bin:$PATH[/tt] just on top of the shell script that calls the makefile. You'll find this in the info-panel of your target. maybe it's not that simple, then: have you generated a makefile with the mkmk.pl script? You need to do this, because it looks like you want to run the makefile for windows (I noticed last time on win, that the make.bat command actually involves this script (./mkmk.pl) I am also very unsure where the calls to MIOSStudio should come from. Normally this has nothing to do with the compile process ??? Anyway, to get the new makefile you have to: - open MAKEFILE.SPEC and change the project name and add additional source files you may use to MK_ADD_OBJ. - then open the terminal and type: [tt]cd [/tt](drag the folder of the subdir "tools" and hit enter) [tt]./mkmk.pl MAKEFILE.SPEC[/tt] A new makefile should have been generated for you now. Make sure it's in the root directory. A variant of this is described here under "Setting up the Make Target": http://www.midibox.org/dokuwiki/doku.php?id=how_to_use_xcode2_as_ide_on_a_mac After that, you should follow the next step: "Setting up the primary application target". It's simply a new target that does nothing else than calling your new makefile. Did this help? Best regards, Michael

ehrm. no. :-[ but such a pin would be pretty nice to have... hehe, think of an orange lighted pin on your jacket that switches on when your input-buffer is half full and a red one which burps if it's really **full** ;D

yeah, or think of just a simple bar animation that may sweep to left or to the right, or in case of a tilt-sensor some animated fluid. :) nice ideas...

oh, cool; I didn't know the "hyperactive" one yet :) I just love this! Cheers, Michael ps: http://www.youtube.com/watch?v=5n6F51NMzGk

hm, I haven't really figured out how these should work exactly, but reichelt.de has these: Prod.# DTL 2 (+ color ID) You can mount your own LED in (buttons are sold without LED). For illuminated Buttons in general, you should search the forum, it's a topic with a lot of threads. Regards, Michael

hmm, one could mount it on top of 4 tiny switches. so you could have kind of a menu selection / directional button. or even cooler: using it with a tilt sensor 8) (ohh, I have too less time for all this) ;D Michael

my last reichelt order came yesterday, so it's a bit of a bad timing; but if you're not in any particular hurry, we can do it that way :) (and price is free for you ;) ) and because I saw your question too late: I guess that Mike has burned the 1.0 fw onto your PIC16F88, because I don't think he grabbed the 1.1 update from this forum page. but as I've written before, the only difference to 1.0 is that the IIC-input buffer is a bit decreased, so that chances are lower to overfill the SpeakJet's input buffer. But I see this as a temporary fix only. The only really cool solution to it would be to connect the "Buffer-half-full" and "Buffer-full" pins of the SpeakJet to the PIC16F88 and control the buffer dynamically. That would reduce the amount of these annyoing pings one can hear from time to time if there are too many messages sent. Cheers, Michael

no prob, I will update the whole sources the soonest in two weeks anyway, so change what you like. As I have only worked upon the speech part, I really like it that you provide new and updated stuff for the synth part :) I posted the new fw here, a few messages above (that one with the updated uart.asm code-snippet; attached a zip file), but I'd really appreciated it, if you would keep your fw 1.0 just for some weeks to see if that issue hits you too. that would be really interesting! (but of course it's up to you...) I will also enclose the whole updated fw incl. sources with the next release! Cheers, Michael

no, definitely not. I have two SJ-IIC-Modules and two cores, ie two totally independent SJ-projects I never mixed up. One has a Core from Mike & SJ-Module v1.0, the second one uses a Core from SmashTV & SJ-Module v1.3. Because I had a soldering error on the first board (killed my blue backlight :'( ) - I thought this might have damaged something and began from scratch. That also explains my panic when I discovered the same startup issues on the fresh second board(s); both showed exactly the same behavior: everything was fine for quite some time - until I plugged them off and took 'em somewhere else. Both times the Startup-Issues began then and got worser. Maybe this has also something to do with using a switch (IIRC I soldered a power-switch both times shortly before having to move the whole stuff). I also tried with fw 1.0 (the original one, reburnt, fresh PIC16) but it did not help. Besides, fw 1.1 has only a reduced IIC-input buffer. Due to my compilation problems with ASM-based projects on the mac, I have checked the modified hex-files byte-by-byte, so I am pretty sure, that the .hex-files I uploaded were okay (besides that the burner software shows an error if the .hex-file is damaged). I also tried four different PIC16's! Very unlikely that they all were somehow "damaged" :) Now on both my modules the error has vanished (until now, fingers crossed). I expect that you will sooner or later stumble over this behavior, too. If this is the case, I can burn the new fw for you. But this should not be necessary until the problem shows up. An MBHP-Burner and a PIC18->PIC16 Adapter is used. Flashing just takes a second and is pretty straightforward :) Best regards, Michael

hey, still looking good. switched the box on/off very often. once I heard one ping (and then my heartbeat, 'cause I thought the error would be back), but it was only one sonar ping and then everything started okay. I'm pretty sure that this was one of the moments where it would start with the wrong baudrate (with the old firmware). So my optimism grows daily that this strange thing has been fixed. And I can now compile the PIC16-fw on windows (still strange that GPUtils won't compile the project correctly under OSX, but the same tools will do fine on Win), but anyway, I'm digging into that later. It would be nice to have a firmware that checks the SJ's buffer state and the integrity of received messages. But that's a future thought, now I'm first going to record a video of the new sensor matrix 8) see ya, Michael

hey stryd, you're being missed in the #irc ;D anyway: I got two SJ's and two boards (and two cores, of course). The new PIC16F fw did the trick on the old board too! but the old one does not reveal that one sonar ping either. But I can't remember having hear the sonar ping ever :-\ And I'm very lucky that I don't hear it anymore!!! ;D cheers, Michael

All right, I'm carefully optimistic :) Thanks to stryd, the chat was really helpful. I think the pointer to the baud sync was right. Stryd suggested, that I should add a short delay between the pin going low (M1) and the 0x55 sync byte. So, uart.asm is now looking like that: ;; -------------------------------------------------------------------------- ;; FUNCTION: UART_SpeakJetInit ;; DESCRIPTION: initialises the SpeakJet baudrate by using the detection ;; IN: - ;; OUT: - ;; USES: - ;; -------------------------------------------------------------------------- UART_SpeakJetInit ;; reset SpeakJet, enter baud rate configure mode bcf SPEAKJET_RST_N_PORT, SPEAKJET_RST_N_PIN ; low active! bsf SPEAKJET_M0_PORT, SPEAKJET_M0_PIN ; enter demomode bcf SPEAKJET_M1_PORT, SPEAKJET_M1_PIN ; baud rate configure mode ;; initial delay call UART_Init_Delay ;; release reset call UART_Init_Delay bsf SPEAKJET_RST_N_PORT, SPEAKJET_RST_N_PIN ; low active! ;; (we hear a "sonar ping" sound now!) ;; now wait until the SJ has catched up call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay ;; continue with baudrate detection: send 0x55 to SpeakJet movlw 0x55 ; write to TXREG directly - should only be done during initialisation phase! movwf TXREG ;; wait until byte has been sent SWITCHBANK_0_1 UART_SpeakJetInit_TxPoll btfss TXSTA, TRMT goto UART_SpeakJetInit_TxPoll SWITCHBANK_1_0 ;; wait > 2 mS (just an assumption, it could also work without this delay) call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay call UART_Init_Delay ;; go back to normal mode bcf SPEAKJET_M0_PORT, SPEAKJET_M0_PIN ; suspend demomode bsf SPEAKJET_M1_PORT, SPEAKJET_M1_PIN ; leave baud rate configure mode return ;; subroutine which causes a delay of ca. 150 uS @ 20 MHz UART_Init_Delay clrwdt clrf UART_DELAY_CTR UART_Init_Delay_Loop decfsz UART_DELAY_CTR, F goto UART_Init_Delay_Loop return [/code] Recently I had about 65% errorneous startups. Since I updated the PIC16F88 to the firmware 1.2, I tested it about two dozen times with 0% errors. I tried it fast, slow, continouus and I even pretended a walk and presentation in the college ;D So, wish me luck this fixed it! I attached the new hex-file for mbhp_iic_speakjet_v1_2. The complete sources will be part of a download package that I will release soon! Now I hope that this really helps fixing the startup sync issues. Thanks to everybody, I really appreciate all your immediate help. That's what I love about the midibox community. :D Cheers, Michael ps: a movie preview will follow asap!!! puhhh, it's good to feel some optimism coming back to me :D mbhp_iic_speakjet_v1_2.hex.zip

Hey, stryd! That's great! I'll take a huge cup of coffee first, then I'll take a look into the PIC16F code and take a visit in the #midibox chatroom. As this error has occurred to Rio too, I'd say the problem is not so much the delayed startup of MIOS, but rather somewhere in the baud-setup in the PIC16 Firmware. See you later -

to 1: I can hear 1 "eh" or "ready" and afterwards 4 Sonar-Pings. this is just sometimes! and that's what puzzles me. It's totally unpredictable. So my problem is not, that it does not start at all. My problem is, that it does not start correctly sometimes. And I fear that this "sometimes" increases over the time. to 2: Normally this is only if I have a Midi-Cable attached and the MidiServer is not running (on the mac). But if there's no Midi-Connection, it's starting up. But maybe this is the reason for a short delay that disturbs the syncing sequence; that's why I mentioned it. Elsewise I have no troubles with MIOS. I really think (hope?) it has to do with syncing the SpeakJet and setting it to the BaudRate of 19200 (the SJs default baud-rate is 9600). I need a break and some sleep... will be back tomorrow morning...

Hi Rio, that's indeed interesting! unfortunately the boards are screwed inside a box that's screwed on a podest. :-\ no chance of getting to the IIC wire easily. I need to find out if this is a problem of the SpeakJet, the PIC16 firmware (syncing) and/or the IIC-Connection to the Core. If I remember right, last time this happened (with my old boards) I hooked them up to the PC (via RS232) and set the baud rate with the Phrase-A-Lator Software... which brings me to the idea of setting the baud rate manually: Does anyone know how I can set the M1 (Mode Select) Pin to momentary low? And then sending a sync-character (hex 55). Is something like this supported by the PIC16 Firmware? Uhhh... (thanks Rio for the cooldown. the thing is, however, that I have to get this working in the next days. If not, I'll have to reprogram it on a mac... which would really annoy me after all the work I've put into this little thing) Edit: Already tried this. I think I can relatively safely assume that it's nothing to do with the AINs. :-\ really appreciate your help!

Hi everyone, I'm in big (big!) troubles: after soldering a complete new core board and SJ module, everything worked quite fine for some months. But today I had exactly the same troubles than described above. Sometimes MIOS isn't starting up properly: the result is that I can hear about 4 sonar pings. Then I guess the SJ is using the default baud-rate, because all signals are dreadfully mixed. However, this behavior now comes up every time I'm switching the device on. Every fifth time or so it starts up normal and everything is okay. But the next start it's happening again. I tested out different voltages from 9 to 12V with an 800 mA power supply. No success. I disconnected all unnecessary connections one by one without any success (besides the current equipment is 1 Core, 1 SJ-Module, 4 Distance-Sensors connected unmuxed to the Core. Is there a way I can deal with that? Am I the only one that discovers a delay in MIOS when Midi-Cables are connected but the connected devices are offline? Would it make sense to use the default baud-rate? How can I debug the Core-Module and find out why there's sometimes a delay in the startup-sequence? There's an exhibition scheduled next week and I'm totally upset about this, because everything went so great in the past few months. :'( Any help or thought would be desperately appreciated!! Best regards, Michael

Anti-Punctuation rocks! (And I mean that honestly!) Cheers, Michael

hehe... Hi Seppoman :) Honestly I haven't worked with any AVR. I just remember having read a longer post from TK about that issue and it sounded like there were some good reasons for that opintion. But the truth is that I was tired of searching the forum. Of course you're right; I should watch my words when there's no real experience behind :-X :) Cheers, Michael

So, I guess with "DSP" you mean you want to do audiosampling, then frequency detection and then Midi-Conversion? Is that right? This is not part of MIOS and I guess even if you're an advanced programmer this is a challenging task. Don't forget that we're talking about tiny microprocessors here, so the problem starts only when you have to deal with multiplication and division. And it's not getting easier when you want to process floats, which you'd have to when dealing with frequencies! Doctor Float and Mr. Division kill your little processor's power faster than you can say boo. :o I wonder, if you're using a PC anyway (you're talking of some VST stuff), wouldn't it be possible to transmit the audio signal and do the frequency detection stuff on the PC? I guess there are some dedicated programs available for that purpose. There is no DIY solution for wirless midi transmission to my knowledge up to now, because of various problems of possible signal loss. There is however a device from M-Audio that might interest you 139,- EUR. I guess this task alone would cost about half a year development time at least (!) to get useable results. http://de.m-audio.com/products/de_de/MidAir-main.html So, have I been discouraging? Sorry, didn't mean that ;D ...at least I'd be happy for the DIY-community if you prove me wrong! ;) ;) And if I totally misunderstood you and you just want a MIDI-controller for your VST software, then go ahead and build a Midibox64 (maybe you could do a small SMD board, I think I've seen someone doing that) and forget about AVRs, 'cause the PICs used for MBHP are better suited for MIDI-Tasks than AVRs. Besides there is no need to re-invent the wheel. And you don't need no expensive Development Boards with MBHP. That's pretty straightforward with the Bootloader-/MIDI-Approach of MIOS. Best regards, Michael

Hi, also, es gibt diese taster zu kaufen, ziemlich teuer, aber: http://www.midibox.org/forum/index.php?topic=7116.msg48744#msg48744 http://www.sparkfun.com/commerce/product_info.php?products_id=7835 (buttons) http://www.sparkfun.com/commerce/product_info.php?products_id=8033 (platine) ich denke nicht, dass die leitende fläche tatsächlich sehr elastisch ist, denn die meisten knöpfe sind ja so angelegt, dass sie erst mal nicht leiten und nur wenn man den "knackpunkt" hinkriegt flupsen die um und leiten. naja, ziemlich schwierig zu beschreiben... außerdem ist moxi im französischen teil des forums recht bewandert in silikon-produktion. es gibt auch einige topics auf englisch: http://www.midibox.org/forum/index.php?topic=4997.0 Grüße, Michael