stryd_one

Two problems there: The info isn't there to copy and paste. Some of it is, but it's not complete. You shouldn't duplicate info, that makes updating a problem. You just link to the correct info, rather than copying it. And that's what we have now.

You shouldn't have a 7809 on the core......

Jamie: You broke one of my studio rules - no drinks without lids. One day you'll knock one of those glasses/cans over and you'll know why I have that rule Sasha: I hope you don't wear polyester fabric, or your lab is a static discharge waiting to happen Jidis: I have a big box for the delicate parts which are waiting... cost me $10 and I know I'm not gonna smash any sids ;)

Sweet hack! Blog this sucker already! :D

Tip: scratching xfaders are logarithmic response so they don't translate well to digital use (midibox for example) You'll want to go with infinium faders if you're really choosy because they're dj-targetted, and available in a linear response.

Good mod! Don't forget, ART is a budget audio manufacturer....

Correct. Perl dislikes long file names, so you need 8 characters max, no spaces and such. It seems that your system might be using the DOS 'find' instead of the posix one. can you try typing this: find --version It should return: GNU find version 4.1 Can you also type: path and paste the results here.

jim: You can buy a JDM from smash to burn the PIC16F. I think you'll find hits from the search engine about the soundgin, it has been discussed in the past. AC's project focusses mostly on the speech from the SJ, but a synth app with the soundgin would be interesting. Let me know if I can help :)

The FAQ on the wiki, and the relevant pages for the project (SID) and modules (Core, DIN, DOUT, SID etc) which you will use should be the first stops. Well there are two problems with that approach. The first is that the projects all differ, so a 1,2,3 approach would have to be written for each project, not to mention one for each OS platform (unix/macos/windows). That's a LOT of doco. The second, most impacting issue, is that the documentation doesn't write itself ;) It's all done by volunteers. I'm on a path to having a generic (non-application-specific) process which starts with "I have a bunch of money and time and I want a midibox like 'that' one (and I use windows)", and steps you through it - but such a series of documents is complex and time-consuming to write in a useful manner for everyone (newbies and gurus alike). If you'd like to volunteer to help out then by all means do... but somehow I don't think you have the time right now, just like the rest of us ;) So, at the moment, the best thing to do is to read the basics (some mentioned above, and some others) and then use the search engines to find answers to any specific questions you have along the way. Of course, if you don't find the answers after a thorough search and browse around, then you can post and we'll help you out....but there's no quick and easy way.

Sorry the quote was delayed a bit while I was working on some other stuff, I'll email it off tomorrow (won't get a chance today)

Ahhh I see now! Good on you for considering future builders, that's awesome :D Clearly this is somewhat organ specific - a subject I'm not entirely well versed on, so I'll keep my misinformed opinions to myself ;) Regarding the 'long matrix' idea, you could probably write a driver for 8x128 with some ease, and use #defines to specify the size of your matrix, to limit scanning of each buss to your required size (In your case, 2x128 or 4x64) That'd be good I guess because it would allow for organs with different layouts (like the common busses that extend beyond the keyboards that jim mentioned). I'll butt out now ;) Rock on moonskin!

Heh , it's good to have too many projects, keeps you on your toes! Is that a monome there? THey're a lot smaller than I thought (looking at the ultracores as comparison)

You should store them in your application, no need to mess with MIOS or read code. Hint: http://www.ucapps.de/cmios_fun.html#MIOS_DIN_SRGet I think a 32x8 matrix would be much easier.....

Patience is a virtue ;)

I think (someone confirm/deny please) that the MB64 only supports one encoder for the menu. No rush dude. Just remember, if you take as long as me, people will tease you ;D

well if they run off the same PSU, the grounds will be connected, otherwise, no ;) I think you need to begin a process of elimination, removing things until you find a way to replicate the problem.

Send them to me. ;D Or you could like... try... uhm... what's that word again uhm... oh yeh... SEARCH!!! The first hit if you search for 'test SID', aside from this one, is the one you want ....

Heh, you're gonna flip when you realise how easy it is. Well yes and no. Such a program is exactly what you need...and such a program is just what MIOS is... so you don't need to write very much. You just need to use a bit of simple code to process the incoming midi data. Rather than explain it to you backwards, I'd prefer to use a real world example to demonstrate it to you I was going to write code to show you how to make the robot's 'elbow' react to incoming notes, but first, I think we need a more clear explanation of what you're trying to do. Don't worry too much about how you're going to do it, just what you're going to do.... as AC said, it seems as though you want to use existing midi files to control the robot, but I'm puzzled as to why one would want to do such a thing. What's the end-goal here?

The debouncing happens as the DINs are scanned, and then the NotifyChange function is called after it is complete. The Tick function is separate, it just loops around whenever MIOS is not busy doing something else (like scanning the DINs) It's not really documented because you shouldn't need to worry about it, MIOS does it for you ;)

Thanks d! LOL!!

I have a new mantra for you angel: Read first, then post...Read first, then post...Read first, then post... I know you're in a rush, but do you have to make your time constraints our problem?

Maybe you should try the same troubleshooting steps.... Seems that this guy disappeared, so maybe TK's hints worked and he forgot to say thanks ;)

I don't wanna interrupt the troubleshooting process here, but that could be bad. You should find the source of that problem before you go on. I'd have my sid chips removed if I were you.... :-X

Yeh I agree, it's nice, goes well with the handles!

Hey boxers! Quick tip for you, regarding the new unified mios platform, and custom linker scripts.... You can specify your own linker script, like many things, in the makefile. Chances are, you'll put the linker script in the same directory as the main.c, right... So you copy your makefile from '\trunk\etc\lkr', into your app's root dir, and you make your mods... Then you edit the makefile. The original: # define the processor, linker file and project name PROCESSOR = 18f452 LKR_FILE = $(MIOS_PATH)/etc/lkr/p$(PROCESSOR).lkr PROJECT = project The mod: # define the processor, linker file and project name PROCESSOR = 18f452 # Custom linker LKR_FILE = ./$(PROCESSOR).lkr PROJECT = project Now, you're probably thinking like "Duh" right about now. But there's one important thing to note there, and it's pretty subtle. This: LKR_FILE = $(PROCESSOR).lkr Will compile. No worries. But it won't work with the dist script. You need this: LKR_FILE = ./$(PROCESSOR).lkr the dot-slash is required. That's all, enjoy!