audiocommander

If I will ever find the time to build a router, I'd customize it in need for a patch manager. The router-project is ideal to observe incoming PRG-CH for each MIDI Line. By storing these values as a "super-patch", it would be possible to send out all stored PRG-CH with one touch :D Best regards, Michael

I see ;) Then you might send Smash_TV a note about to go for sure... Or maybe you wait a few hours, I know Smash_TV looks regularly in this forum, I think he or someone else who knows it exactly can help you with a definitive answer... :)

AFAIK mb64 requires just one Core => no Core linking required => ID 0x00 I have burned my PICs with the default ID 0x00 and never had a problem. Don't know for sure about the MB64 - however, as you seem to be capable of burning your chip, you can always reburn later, if necessary. It's no bad idea using IC-sockets anyway! Regards, Michael

http://www.midibox.org/dokuwiki/doku.php?id=how_to_select_a_pic_id_header ;)

Well, the code is commented very well and explains nearly everything. I understand it does not exactly what you want, but basically it's all there, you just have to use the snippets that are relevant for your needs or implement clock_receive() handlers (which would be a good point to get help from us, because I see that is something more people might request). If you don't understand anything, this might be a bit too complex thing to start with, because divisions (esp. with high numbers) need mixed ASM code and I have to admit that there are some lines I don't understand either, but to be honest: everyone has to fight with some lines of code. Don't give up so fast! All I can say is: the code is there, you just have to use it. If you have specific questions and I know the answer, I might help, but I'm not going to do all the work for you (at least not now, maybe in a few months when my other projects are finished ;) ) Good Luck! Michael

http://www.midibox.org/dokuwiki/doku.php?id=encoders

no, a rotary encoder is (as the name applies) a digital encoder (= "step-button") and no potentiometer. it sends out a signal on each step. the number of steps depend on the manufacturer of the encoder. the led-rings are very useful to indicate the current setting of the encoder. with faders, you'd need very expensive motorfaders to achieve the same result.

You should set the AIN_DeadbandSet(7), so that it's optimized for 7bit values. This is also the default setting. Remember that it's a 10bit value in <pin_value>. 10 bit means a range from 0 to 1023! And that means you should invoke an if-statement: [tt]if(pin_value > 512) { // ON } else { // OFF }[/tt] ;) Michael

I actually enjoyed the smiley ??? ;D But you haven't looked at the clockBox source in detail, haven't you? => void MCLOCK_BPMSet(unsigned char bpm); unsigned char MCLOCK_BPMGet(void); unsigned int MCLOCK_GetTimerValue(unsigned char bpm); It's all there, the formula, the cycles, ASM-optimized divisions... you just need to crunch it down to your needs and implement a MIDI-Event notification that substitutes or calls void MCLOCK_Timer(); ;) Michael

>:( Don't ever buy something from Guillemot/Hercules (if you're on a mac). I just had to restart my computer and as a side-effect of removing the kernel extension, I had massive start-up problems and multiple kernel panics - not even startable in safe-mode. Had to remove hundrets of files manually... If you want to access the support, you have to register and then get notified three days(!) later, that you are allowed to complete your profile (= personal data) before even submitting a question >:( >:( grrrr.... >:(

just to prevent misunderstandings: ;)

check out clockBox. ...and no need to double-post ;)

http://www.midibox.org/forum/index.php?topic=5962.0 http://www.ucapps.de/mios/mios_ram_handling.txt

AFAIK midi clock is sending 96 pulses per beat. stryd_one is right, I think clockbox shows bpm values.

Hi HawThorn, there are two different ways on how to use buttons without the need of a DIN-Board and that is what you want, right? Further, I assume you want to code your own application rather than using a pre-existing one? Option 1: wire your switches to some spare AIN-pins (J5 of Core). Whenever a pin-state changes, you'll be notified by AIN_NotifyChange(). You just have to check if (pin_value > 512) Option 2: wire your switches with a resistor (!) to any spare pin of the core module. Consult "mios_pin_list.txt" (it's also in the download section of uCApps.de) to find the appropriate pins and their equivalent names (e.g. RA5 for J5, pin4). With this option you don't have no handy notifier function, you'll have to implement some checking method within a timer. If you are not used to C, I'd recommend option 1! However, there is a relatively new thread that covers most of these two concepts in detail: http://www.midibox.org/forum/index.php?topic=6754.0 Hope this helps, ;) Michael

well, I have a small Behringer 12/2/2 Mixer for Live-Gigs (besides a larger Studiomaster for my homestudio) and I won't complain for the small amount of money I paid for. But I noticed, that if the input gain is too low, it's loosing a lot (nearly all) high frequencies. If I get the gain right, it's okay. But I'm not using it for sweet harps'n'whispered poems, you know... ;D

that could possibly be the reason: maybe they got destroyed by soldering too hot & too long :-\ It is said, that some ICs are very sensitive... I think if there's no real good reason (eg AIN "purists"), sparing the 5ct for IC-sockets is actually no good idea... have you tried testing with MIOSStudio? You can directly invoke DIN_PinGet() from the debug-interface (maybe you have to stop the User-Timer first). I have been very lucky for this handy interface when debugging my last DOUT struggles... And if you're working with your own application: have you tried uploading a DIN-example app to see if that one is working? I had some strange errors in the past that were directly connected to some garbage in my code I have simply overseen. I'd check that before desoldering the ICs. ;) Michael

yeah, but the main logic problem is still there and I think it's because switch and if-then-else has been mixed wrongly: AIN_NotifyChange is called if the value on the pin changes! example: change of pin 0 from OFF (0) to ON (1023): [tt]AIN_NotifyChange(0, 1023) { ... }[/tt] example: change of pin 2 from ON (1023) to OFF (0): [tt]AIN_NotifyChange(2, 0) { ... }[/tt] Now please, before posting another question think about that! If you got only [tt]switch(pin) { case 2: ... break; }[/tt] what about case 0 and 1? The code inside the switch-statement will never ever be executed when pin 0 and 1 change, and remember, it's a three-state switch, so if you switch from 0 to 1 the state of pin 2 does not change (it remains OFF). And the worst thing is: if you test it with pin 0 and pin 1, your variable "knob" is undeterminded but used to send values, because it's only the switch-statement which isn't executed, but the SendMIDI-commands are indeed processed! No wonder, there's coming garbage... Please, do proceed as I stated above: - Read again the switch-syntax, you got it twice, from David and me. - Then take yourself a quiet minute, get a pen and a paper, set in real numbers for your variables and test it six times, for each pin (0 and 1 and 2) and each value (0 and 1023) and calculate what happens at each step! It will be quite obvious to you. ;) Michael Edit: and one more hint: go get yourself a code-editor that supports line indentation. It is obvious your [tt]} else {[/tt] is meant to be an [tt]else[/tt] for the [tt]case[/tt]. If you'd have a correct line indentation, these kind of errors would not happen!

fist of all, you don't need not '[tt]int[/tt]' for [tt]knob[/tt], take '[tt]unsigned char[/tt]', it uses just 1 byte instead of 2 or 4 bytes. next, you still haven't got the right syntax: there's only one pin mentioned. you code will only be processed if the state of pin 2 changes: [tt]AIN_Notify_Change(pin,pin_value)[/tt] is only been called if [tt]pin_value[/tt] of [tt]pin[/tt] changes. Read your function line for line in a mathmatical manner and "calculate" about what happens, if it's called when [tt]pin_value[/tt] changes on [tt]pin 1[/tt]! ;) Michael

Have you tried switching the ICs (eg. 2nd with 3rd), so you'd see if you got two damaged ICs. If it's the same result, maybe it's a coding error?

right, it's switch PIN. it's the way I've posted above. that's the syntax switch(pin): case (pin==0): // the pin==0 is just to show you what happens here! // do something break; // end the case and break out the switch; // without break, all the rest would be processed case (1): case (2): // do something for pin 1 AND pin 2: break; default (whatever): // this is the standard definition if nothing matches // it's optional break; } That's all. It's just another syntax for a complex if then else. Maybe it will help you to look out for a good online C-Book, there are some... I noticed one mentioned here in the forum by stryd_one, just a week ago... Best, Michael

Nothing for an iBook, but I'm quite pleased with my M-Audio Delta 10 card (G5). The driver supports multiple Delta-cards, so I think you can chain up to four of them ;D I'm currently searching for a Firewire Interface and I have to warn you about that super-cheap Hercules 16/12 FW Interface (~260 EUR). The first one I got was damaged (no LEDs), the second one caused (reproduceable!) severe Kernel Panics on both my G5 and G4 PowerBook while uploading SysEx-Messages (at once) and by good MIDI-Traffic (after 2 to 3 hours). The driver and support for Macintosh is real crap. Dunno if it's better on Win. Save your bucks for this and spend a bit more on quality products... I'll report my decision next week, when I return the Hercules Interface (if I don't forget ;) ) Michael

Hi Mark, although you could possibly wash my bike, I don't think that's needed ;D some comments: 1. if you're using a [tt]switch[/tt] case, there's no need for [tt]if then else[/tt] 2. pins are counted from 0, not from 1. So if you connect your switch to pin 1 and 2 you have to address them as 0 and 1 3. you're asking for [tt]MIOS_AIN_Pin7bitGet(pin)[/tt] both times but pin is an overgiven value (see the AIN_NotifyChange parameters) 4. instead of calling [tt]MIOS_AIN_Pin7bitGet[/tt], you could also invoke a tiny bitshifting calculation: [tt]pin_value >> 3[/tt]. That means division by 2 with every bit (here: [tt]pin_value / 2 / 2 / 2 [/tt]). I don't know though which one is faster. I'd assume the bitshift, but I really don't know. void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam { switch (pin) { case 0: if(pin_value > 512) { MIOS_MIDI_TxBufferPut(0xb0); MIOS_MIDI_TxBufferPut(0x5b); MIOS_MIDI_TxBufferPut(MIOS_AIN_Pin7bitGet(pin)); } break; case 1: if(pin_value > 512) { MIOS_MIDI_TxBufferPut(0xb0); MIOS_MIDI_TxBufferPut(0x5d); MIOS_MIDI_TxBufferPut(MIOS_AIN_Pin7bitGet(pin)); } break; } Keep it up! (wasn't that difficult, was it?) Cheers, Michael Edit: I just noticed, there might be a misunderstanding => right now, the code sends a message ONLY when the switch gets closed (>512). To implement an action if the switch is released you can add [tt] } else { ...[/tt]; but it's apparently that pins 1 to 2 are NOT pressed, if pin 0 is active, so you can implement your logic in the appropriate case section... hopefully I haven't confused you now... ;)

nice show :) I stumbled upon synths as a singer, it's interesting to learn (and hear) about synth-history. Thanks for sharing :)

Is a good idea to have a union? So that a 64-byte "value" can either be treated like a structure (for variable access) and on the other hand be read out as a 64-byte value. I want to have a clean storage implementation, but I don't know if nested variable access is slower or this has some other impacts I haven't thought about... Thanks for your comments! Michael