stryd_one

No apology required mate! :) I think I can safely speak for everyone when I say we're glad to have the forums here at all. A day or two's outage is not so bad :) Of course, they went down when I was due to do a big batch of soldering and I didn't have all the doco I needed. It sure was bad timing! I assume that you've been working on this too, so I hope you get some sleep soon mate! Now hurry up with the wiki already! ;) Just kidding :D

Thanks Twinny!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Yay! I never want to see this: Index of / Name Last modified Size Description -------------------------------------------------------------------------------- Parent Directory 14-Oct-2006 17:21 - cgi-bin/ 14-Oct-2006 13:57 - -------------------------------------------------------------------------------- Again!!

Doesn't look like it.... I've had a quick read... this error seems to occur when the types don't match... You mentioned this: unsigned char stored_pin[13]; stored_pin[0] = pedal_group_stored_pin; stored_pin[1] = tremelo_strength_button_state; Caused an error... I think that's right. Now, I'm new to C, so bear with me if I'm wrong but... When you declare unsigned char stored_pin[13]; That means that the array should return an unsigned char... I'm willing to bet that the 'tremelo_strength_button_state' is a boolean value not a 8 bit char? Maybe this will cast into the right type, I'm not sure? I think fluke is on the right path. I'd recommend checking that your types all match up the way they should.... Maybe try declaring a bunch of dummy variables and put those in the array and see if it compiles?

For those who missed it: http://www.midibox.org/midibox_gallery/elektromeier4.jpg This concept came from here!

Both in this case... The value will control the range of voltages output, and the tolerance the accuracy of the different levels.

*Looks at his 6 pairs of SRAM IC's of various capacities* Let me know if you need a hand.... Looks like it's well under control, but just wanted to offer my support :)

LMFAO ;D

http://www.stekgreif.com/mainpage.html

The 1% tolerance resistors you would want are usually more expensive.... Maybe you found a good deal :) The cheaper resistors are 5% and they're not really accurate enough for the aout module...

I'm just glad you reminded me about this!! ;D Well the good news is that the scale engine has been implemented in the new MBSEQ beta (see the other thread) which was really the hardest part about this. Now making this controller is a simple matter of incrementing/decrementing a variable and passing it to the existing engine :) Bad news is, I am going to be unavailable to do it for a long time, I've got other projects I need to focus on for the meantime.... I hope someone will find the time to build this before I do :)

Just a quick update, I have done some work on this, basically the way it works is that it stores the last played of each type of midi message, so they can be used as modulators for messages sent in real time.... You set up as many 'operators' as you want, and when a message is sent from the keyboard to the core, if it matches the input filter of the operator, the message is combined with fixed parameters, user-selected values, and/or the stored input from other messages, to provide the output you require. This sounds more complex than it is ;) I'll give some examples.... Lets say you select the traditional midi mapper operator. You set it to accept midi note ons/note offs, on channel 1 (because your controller is stick on channel 1 heheh) , in the range between C2 and C3... You select a note shift of +12, and a channel shift of +5, and it will output notes on channel 6, between C3 and C4 Or you could use an operator which maps the last received CC#1 (modwheel) value to the velocity of the incoming notes, so you can use the modwheel to control velocity.... and then use the incoming velocity to set another midi CC like filter cutoff.... I know that's not a great explanation but I've done too much typing this week already so I hope this makes it clear enough! :)

And it supports multiple outputs, so you could, just for example Ryk ;) modify it to drive DOUTs for your analog drum gates when you select a certain output, without removing the normal midi capabilities :D ... But that's a thought for another thread :)

Is it the last two in series? Or do the same two modules seem dim no matter where you solder them?

heh, I always wondered if there was a "right" way :D

Great news, good to hear it :) I'd sure like to see the mods you made, could you put them on the wiki? Thanks!

Search engine dude... :) Basically it means that the core sent an upload request when mios studio thinks that it shouldn't have - IE you're uploading the app already, but it's asking you to upload the app.... So maybe the core isn't receiving properly.... Search results will yield a better answer :)

LOL ;D

There's a PDF doc called sdccman.pdf that has a bit of info in it that might be worth checking out.... Edit: Oh and the Sf.net forums for SDCC can be really helpful sometimes too!

Ahh but what about loading patches? That's the real reason to want to save it or control it by midi.... That'll be the log curve on the outputs, the resonance is a peak and gets amped more... Maybe... I think ;)

That's another way to implement midi control but the big question is whether the new MBSID has space in a patch to save the feedback levels... If not, then the level couldn't be saved in a patch....However, a DCA or VCA could be set to 0 feedback and switched to ground when a patch is loaded, and set by a CC with just a little extra code, and you could send the CC at the beginning of your song to set the feedback as required.... This is starting to sound like a daughterboard hey?

Yes it does! But I never know what to do in these situations.. I mean, can you use it any other way? Is there any purpose in leaving it as-is?

Ouch! Maybe the next ones ;) Must be the card reader bumping the price :( Thanks for pointing it out tho man!

You might wanna take a look at the indispensable sdccman.pdf as well... I've got a vague memory that some of the C stuff uses the stack and might be overwriting your locations. As said above, you could try storing the stack pointers in your own variables at the beginning of the offending function, but I'd also be looking at this sentence closely: Have you tried disabling interrupts?

Well seeing as there's already a midibox wiki maybe just link it to that? 8)