audiocommander

Hi Justin, bit 3 of 238 / EEPROM is called "AutoSilence". Don't know what that means, but it sounds suspicious... you can find the details in the manual, p.11 Don't forget that you have to send these values also as single separate chars, but as far as I see, sending '0' (0x30) should do no harm for address 238 (but pls. check again before trying esp for TTL/RC section of bits 5 and 4... not sure about that, although I think it's just the RC input of E6/E7!) Cheers, Michael

hey stryd no hurry :), please don't stay awake just for that (although it's very kind from you!!) I was about to test this before replying... (but if you're still awake, you know that the australian team is currently playing against italy at the world soccer cup? :) Your country is playing well!) I'll check this out with the changes in the wrapper (I also had these thoughts, but my knowledge of asm is so poor I couldn't figure it out...) and report back! Cheers, Michael (holding my thumb for the soccaroos... sorry to all Italians :) )

oh, thanks Unfortunately it has been a total desaster getting SDCC to work on my mac. I couldn't compile the source and it took me weeks to find some precompiled binary versions... however, I will test this on my ol' PC with SDCC 2.5.0 when I'm back (just have my PowerBook with me atm.)... So you think the asm-code in the wrapper is okay? ...because it works with the call to MIOS_LCD_PrintBCD5(unsigned int value) but it does not with MIOS_HLP_Dec2BCD(unsigned int value)... and the asm-code in the wrapper is also different... that's what puzzles me a bit... but as you know I have no clue about ASM... think I'm going to write a new testing app starting with a blank skeleton, maybe it's my source that got screwed up, after all...) Cheers, Michael ,)

haha.. I know that... :D (must be a relief for you that IE7 finally supports tabs now, he ;D :P ;) ;) )

hi stryd_one ;) it's 2.5.4 ==> mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.5.4 #1189 (Dec 30 2005) (UNIX)

hey, thanks that you like the example... For my departure delayed, I get another chance to answer ;) ==> both values are hex! it's just that MSA accepts numbers (so if you want to play the allophone 171 just send the number 171 (0xAB) - and if you want to send an SCP value, you have to send as single ASCII chars ('1', '0' => 0x31, 0x30) I also added a control overview to the wiki, where the separation between MSA and SCP gets clearer (something like an explained definition listing)... I am now two weeks in Hungary following the traces of Baron Wolfgang von Kempelen, who invented one of the first speech-machines around 1773. I'll release the code afterwards, that will (hopefully) be enhanced enough to support all main tasks of the chip. I tried to focus on clean code separation, so anyone is free to use the Midi-Receive Controls I already implemented or just access the huge IIC_SPEAKJET_FunctionLibrary() 8) Cheers, Michael btw: I would need help from someone knowing ASM regarding the C-Wrapper and the Dec2BCD Help-Function; I think the problem is in the wrapper, where the ASM-function has to be called with the lower byte in WREG and the higher byte in MIOS_PARAMETER1, but I'm not so sure, the wrapper does it correct? If this is fixed, the app would support taking 14-bit values to enable seamless frequency controlling.

yipee, mine arrived today (I'm in Germany and surprised it's been so fast :) ) thanks! best, Michael

Thank you Thorsten! As I can see from the mios_hlp.inc it all works correct if I would only use it correct! [homer]d'oh![/homer] If I send 0x00 in WREG (lowByte) and 0x1 as PARAMETER1 (highByte) for 256, I get 0x56, 0x02, 0x00... of course! I don't want to steal your valueable time, TK (and I cannot proceed with this the next two weeks, either :) ), but maybe one of the ASM-cracks here has an idea about the wrapper-code? Even when I'm sitting in front of the Instruction Set Summary it's all a bit like chinese to me :-[ The concept should be the same for MIOS_LCD_PrintBCD5: before calling the function, the [tt]unsigned int[/tt] parameter has to be splitted to Low-byte in WREG and High-byte in MIOS_PARAMETER1. I notice a difference in the wrapper for these two similar functions, but I have no clue what FSR* and PREINC* do... to be honest, I'm not even sure if mios_wrapper.asm is the right place to search for... :-\: (I tried to use the lines from BCD5 for the Dec2BCD, but apparently this did not work) ;; copied from mios_wrapper.asm ;; -------------------------------------------------------------------------- .MIOS_HLP_Dec2BCD code _MIOS_HLP_Dec2BCD global _MIOS_HLP_Dec2BCD movwf MIOS_PARAMETER1 movff FSR0L, FSR2L movf PREINC2, W goto MIOS_HLP_Dec2BCD ;; -------------------------------------------------------------------------- .MIOS_LCD_PrintBCD5 code _MIOS_LCD_PrintBCD5 global _MIOS_LCD_PrintBCD5 movff FSR0L, FSR2L movff PREINC2, MIOS_PARAMETER1 goto MIOS_LCD_PrintBCD5 I know I could simply try the asm code from mios_help.inc, but if there's an error in the wrapper indeed, it would be best If I could fix it there, I think... thank you all for your comments and help! cheers, Michael

Hi Justin, that's right, the allophones have a predetermined length, so you cannot hold them, except if you're using SCP (that's what's working with my version already :D ) MSA commands go straight into the 64byte MSA-input buffer and will be processed fifo (first in first out) while SCP commands have their own 16byte SCP-input buffer and will be processed at once, ignoring any scheduled MSA commands. That means you can alter the MSA sounds while they're playing by SCP (and therefore stretch and glitch). Maybe you also want to take a look at the MSA-controls, because you can also stretch the length with the speed setting from veeeeeeery slooooowww to vry-qwik :) In general, all MSP commands have to be sent as hex (decimal numbers, 8bit max) and all SCP commands have to be sent in hex (single ASCII chars, so 1 would be '1' or 0x31). My version is working quite well, there are just three things I want to work on / fix before releasing something: - the 14bit to single ASCII char function (I think I found the problem with HLP_Dec2BCD, but can't fix it by myself, see that thread) - the Envelope Control (controls the mixers) - phrase storage (the step record with preview and undo step works quite well, but I haven't implemented storage on the EEPROM yet... Cheers, Michael ps: I uploaded an mp3 file here: recorded it yesterday, not an artistic file, but shows what is possible with the current state of my app; you can hear how I control the five oscillators and later on mix it with MSA allophones (all from my Korg microKONTROL, so this should be easily controllable by any other midibox 8) http://www.audiocommander.de/downloads/midibox/SpeakJet_AdvancedPossibilities.mp3 (3.1 MB, 32kHz, 80kbps, lowQuality encoding!)

Hi, I couldn't leave my fingers from continuing debugging: MIOSStudio beta7.2 does not support returning values or reading SRAM, so I tried it with beta5.1 which works :D - When I call [tt]MIOS_HLP_Dec2BCD()[/tt] with the decimal number [tt]255[/tt] in [tt]WREG[/tt] from FunctionBuilder, I see: [tt]WREG: 55 MIOS_PARAM1: 55 MIOS_PARAM2: 02 MIOS_PARAM3: 00[/tt] (right!, hex) - When I send the dec number [tt]256[/tt] I get: [tt]WREG: 00 MIOS_PARAM1: 00 MIOS_PARAM2: 00 MIOS_PARAM3: 00[/tt] (wrong!, hex) [tt]WREG: 000 MIOS_PARAM1: 000 MIOS_PARAM2: 000 MIOS_PARAM3: 000[/tt] (wrong! dec) :D ...but I don't know if the 8bit restriction is due to MIOSStudio or a problem in the Wrapper or inside MIOS? :'( Cheers, Michael ps: The outputs of "SRAM Read" from address 0x003 (No.Bytes 0x3) are: [tt]255 => 3: 40 00 00 256 => 3: 40 02 00[/tt] which is not what I expect to find at addresses 0x003, 0x004 and 0x005 (MIOS_PARAMETERs)

Hey, no need to say sorry, that's exactly what I wanted to hear in the first run ;D (I'm always a bit stressed if I post a question, because in 98% of all cases I've been beaten with incredible blindness :) ) hmm, but 8bit are 255 max, which would be a char, right? ...But I feel this is the right direction, think it might have something to do with my unsigned short instead of unsigned int declarations, maybe this has been a bit toooo optimized :-\ I'm going to interspect this when I'm back again in about two weeks (look up SDCC int/short specs) and report... Thanks again for your help, stryd! :) Cheers, Michael

;) yes :) ... that's only my tweaking code for the debugger. I posted it because it does what I expect MIOS to do... and because the numbers match if I debug it, but it produces just trash if run on the PIC. The actual application code is in the lower code-box... :) Thanks mate!

thank you, TK! I will interspect this (short on time, too ;D ) and report back. I temporarily fixed this by hardcoding notes-to-frequency-as-single-ASCII-Char output, which I wanted to do anyway, so this is no super-urgent issue anymore; however I am still interested in finding the cause of this strange behavior, because a seamless 14-bit resolution frequency control would be a nice feature for the speakJet :) (but no need for you to invest your valueable time in this, I'm sure, I'll find the bugs... and some mates from the SpeakJet thread wanted to post their opinions, too :D ) Cheers, Michael

okay, I'll give it a try: I don't know about pin 45 (AIN has only 32 inputs?), but I assume you have 23 analogue inputs and pins 24 to 26 are your switch and remember: I type without having tested this! You still have to try to think with me, and I'm not perfect either! :) let's define some values to increase readability: #define SWITCH_STATE_UP 24 #define SWITCH_STATE_MIDDLE 25 #define SWITCH_STATE_DOWN 26 this is your mapping: (I hope this multidimensional array works, haven't tried it!!) // adapt these numbers to your needs, // these are basically three arrays filled with 24 values // just fill your mapping with different values. // if switchState is UP (24) it'll be the first mapping (mapping[0]), // if it's MIDDLE (25) it's the second and for _DOWN it's the third (mapping[2]!) const unsigned char mapping[3][24] = { { 0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0x10, 1x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 }, { 0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0x10, 1x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 }, { 0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0x10, 1x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 } } it's better to introduce another variable so we can easily track the setting of the switch: unsigned char switchState; now, we go to the Init() section, where we have to setup the AIN-module and set the inital switchState: void Init(void) __wparam { // configure AIN MIOS_AIN_Muxed(); MIOS_AIN_NumberSet(26); // read current state of the switch button: if(MIOS_AIN_Pin7bitGet(SWITCH_STATE_UP) { switchState = SWITCH_STATE_UP; } else if(MIOS_AIN_Pin7bitGet(SWITCH_STATE_MIDDLE) { switchState = SWITCH_STATE_MIDDLE; } else if(MIOS_AIN_Pin7bitGet(SWITCH_STATE_DOWN) { switchState = SWITCH_STATE_DOWN; } } and finally, here is your AIN-section: void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam { // check if it's the switch if(pin > 23) { // update switch state switchState = pin; } else { // now send your values // begin stream MIOS_MIDI_BeginStream(); // send note on ch 1 MIOS_MIDI_TxBufferPut(0x90); // send mapped value -> array[0, 1 or 2][pin] MIOS_MIDI_TxBufferPut(mapping[(switchState - SWITCH_STATE_UP)][pin]); // send velocity of 100 MIOS_MIDI_TxBufferPut(0x64); // end stream MIOS_MIDI_EndStream(); } } that's it. And again: it's not tested, just written out of my hand directly into the browser ;) And before you start to make it more complex (eg. sending controllers) give it a try this way, so you understand what's happening here. If you got that, it should be very easy to update it for more complex stuff... Cheers, Michael

I have absolutly no idea what you mean with "watchdog" :-[ but maybe three hints that may be better than no answer at all: 1. you can setup a custom timer (see C-Function Reference @uCApps.de) 2. you can change values in your code by calling the appropriate variable names (I haven't looked up the code, but if the global var is named WDTCONbits you should be able to access it's bits by WDTCONbits.SWDTE = 0; or something like that. It's a bad idea to mess around in the pic18f452.h file, cause this is just a header providing the structure that's inside the pic... 3. you can mix ASM and C code by calling __asm and __endasm; (see wiki entry in appDev: http://www.midibox.org/dokuwiki/doku.php?id=application_development -> how to mix C and ASM. Hope this is of some use, ;) Best regards, Michael

Hey Mark ;) I know it's hard in the beginning, but please take a look into some basic C-books. There a lot of links in the Wiki. C is a very easy language, if you ignore all the bit-stuff and concentrate just on the basic things: - fundamental variable types, variable declaration and -definitions - control flow (eg functions, if/then/else, switches, loops ...) so: if you declare your variable(s) inside a function, what's the scope of this variable? (do you know what "declaring a variable" means?) I still don't know exactly what your ahundredandfiveentriesarray does, but if you let this complex array aside for a moment and concentrate on the logic and getting this function to send the right values, this might really help. of couse! this is exactly what you wrote. pin 0 to 23 is neither pin 24, nor pin 25, nor pin 26. So what happens? Right, just the three lines below are executed. and knob_pos1 and knob_pos2 are undefined (scrambled unknown values!) It might really be of some good if you look into the literature link list of the wiki and print some pages out of your favorite C-book and read about basic variables and control flows. You could get the basics in 1 or 2 days and know what you're doing afterwards, instead of trying and trying for weeks without getting this thing to do what you want. I would really help you more concrete with some lines, if I would know exactly what you want to do ::) Keep it up, man! You're just a few steps from gettin the complete picture and things will become clear as a shiny crystal :) Cheers, Michael (ps: I'm away the next two weeks, so don't think I left you alone with that when I'm not answering the next days, I'll be back to check your proceedings! ;) )

Don't know about Basic, but this is about the midi file format specs: http://www.borg.com/~jglatt/tech/midifile.htm ;) Cheers, Michael

Thank you all :) (I was starting to think that you were all in open-air swimming pools to party the summer... – and maybe stryd_one partying the winter with snowballs in the ice pool ;D ) In the meanwhile I've been typing my fingers bloody and just wrote a MIDI-Note to Freq handler that does it all manually... and is maybe of more use than just a simple OSC-Slider :D ... so no stress, although I'd be still interested why I couldn't get the HLP_Dec2BCD to work :-\ I'll be away for two weeks from Monday on, I hope I can get it to a state where I can release a preliminary zip-file for interested mates here, but I won't get it to the wiki until then... Cheers, :) Michael

No, you should be able to transmit more than one byte between these calls. (although I noticed some unexpected sounds from time to time if I fill the buffer too fast; ...you know that you can store your phrase to the SJ's EEPROM? should work better than just calling allophones; if I understood that right) have you checked on a rs232 terminal what is actually sent? (the pic16 forwards the serial data to the max232) best regards, Michael ps: I'm still struggeling with the BCD conversion, might take another week or two until I release something... (but I'm making progress... slowly but steady ;)

Hey Rowan, I've been curious and read your last question again. Because my last answer is still valid, I want to add for the record: - the .syx file is in the root directory - if you don't change anything, nothing will be compiled (look into the target settings to add and remove files that will be traced upon recent change). a new syx file will only be created if necessary. - the m5_controlStation folder is inside the build-directory, which just contains the debug-application and a folder with the extension .build (just temporary files). Both can be deleted without risk. But I really recommend setting up a new target, it's way easier to type your project-name once and get an overview of how things work, than changing ahundretandfive names in widespreaded locations and getting totally confused ;) let me know how you proceed...

also, ich weiß das ist jetzt gemein von mir schon wieder auf die C-Referenz-Liste zu verweisen, aber leider steht es da: D.h. ich habe es noch nie ohne versucht, so wie es da steht, bedeutet das, dass man es wohl schon weglassen könnte, wenn man keine multiplen Cores benutzt. Trotzdem würde ich es gleich richtig machen, sowas gehört zum guten Code-Schreiben, dass man für alle Eventualitäten für später mitdenkt ;) Also: lieber zwei Zeilen mehr und in Zukunft keine Kopfschmerzen :) Grüße, Michael

and this is exactly, what pushes me towards hardware-solutions. once they run, they run :) no 5-min boot-up, no crash (hopefully!), no $$-greeders and always the best support, thanks to you all and TK :D

Call me sceptical, but I don't think you can measure this with blank numbers. I don't know anyone running his/her window$ not as administrator, just because a lot of dumb software developers force the users to be logged in as admin. Most people even don't know about user rights if you ask them! For example, there were reported some "vulnerabilites" with Mac OS X and great announcements, but in both cases, you had to click "OK" on two dialogues and enter your root-password to get something nasty... so, if that's counted as "vulnerability" and treated equally to some "innocent-browsing-and-unknowingly-sending-worms-to-all-your-beloved-friends-and-working-colleagues-as-well-as-all-your-newsletter-recipients-"... well... ;D ...there's a german saying: "don't trust any statistic that you haven't faked by yourself" :) and stryd_ you will come to the oktoberfest? ;D ;D ...or just joking?

it's from Stanley Donwood who designed it for radiohead's 'OK Computer'... ahh... fresh cup o' oxygen :) ...and always refreshing hearing thom yorke singing "how I made my millions" while his girlfriend is doing the dishes... ;D

yes, I understand, but my understanding is limited: - NI has a closed private beta phase, no public testings, although there are masses of volunteers! - NI denies bugs and declares them as "features" until they make themselfes ridiculous. - NI lies about releasing bug-fix updates "in the near future" ( > 1 year now, have the email here!) - NI introduces new bugs with new versions (I know that can happen, but imho they're simply not betatesting enough!) - minor bugs are not avoidable, agreed. but elementary bugs like hanging notes or unstored prefs / denying of receiving PRG-CH messages is simply not acceptable. this is no bug anymore, this makes the whole software unuseable – remember: I'm talking about being live on stage! Imagine my computer crashes: I would need about 5 minutes before I'm back again. 3.5 minutes are purely related to NI absynth, because it tries to connect to the network (copy protection) and I have to open each instance's window, go twice (!) into deep nested menues to enable PRG-CH's and select Channels before I can continue to make music. and I'm a programmer, too (objective-c / mac), so I also know what I'm talking about. This could be fixed with _very_ little effort and it worked in the versions before, so this is just lazyness or ignorance. And I've seen developers releasing a bug-fix version 24 hours after the first release and these are small companies with one or two people (eg DSP-Quattro) - with even more complex programs that only cost a small amount of what NI takes for its programs. I have absolutely no more understanding for this behaviour and I foresee that NI will be sold sooner or later, if they continue with this. Cheers, Michael.