stryd_one

Well there are two of them... dynebolic is the original, and that team (RastaSoft ;) ) are working on a core (dyne:II) around which other distros can be built, and there's Dhoruba (the new dyne:bolic live CD) and that one you're talking about is called pyre:dyne and is intended especially for PD users. Praise Jah :)

FYI the documentation is updated at last. Code::Blocks changed a lot! It is now necessary to install mingw and gdb manually rather than using the RC installer which has them included... But it runs better and it's not that hard :)

Nice lookin button mox! :) That means that moxi's server is configured to only allow links to be accessed when the referrer is blank or the same domain. Webmasters do that so that people can't embed links to their sites from other sites :)

Whatever works best for you personally, my design will have separate LEDs and buttons...

Forbidden You don't have permission to access /divers/blue_blue_led.jpg on this server. :(

I could be wrong about this but I think SL's are already shielded... I'm sure I remember seeing a foil lining inside there and I don't think it's just cause the designers like shiny things ;) Of course, that's nice, but the platter itself is subject to magnetism so I don't see any way around that. You might find it easier to shield the disk drive than the deck....

Removed cause it was ugly ;)

Thanks TK that new build is off the hook!

I might elaborate more... (Sorry MRE) An LCD screen is the part that shows the actual image or text. These screens need a microcontroller to control which pixels on the screen are on or off (or colours). For the MIDIBox this is the HD44780 (or compatible). This driver enables different models of screens to be easily programmed to work with different MCU's (PIC, AVR, etc) because they are all driven by the same standard protocol, and more importantly it allows a single 8 bit parrallel interface to be used to drive the display. Without this, the PIC would have to drive the LCD's pixel grid all by itself, using too many CPU cycles and IO pins. This means that the LCD driver IC is always the most practical solution, and so when you buy a screen, it will almost always have the driver IC on a PCB attached to the screen. This whole assembly is most correctly referred to as the LCD module, but the term LCD screen is widely used in it's place, as LCD screens are rarely found in any other configuration than as a part of an LCD module which includes the PCB stuffed with the driver IC(s). Hope that helps!

Ahhh now I know what a Priority encoder is :) I have a similar thing in the vX, if adapted to your needs you could use a bitfield and then hold the button states within it, then bitshift it left and count how many shifts until the carry bit is set, or use a for... loop and test each bit from highest to lowest. The counter is then subtracted from the total number of bits and that will tell you the number of the highest set bit. In your case you could optimise this for speed at the expense of code space and ram by holding the current highest button in a variable. When a button is set, compare that button number to see if it is higher that the current highest button, and then setting the current button to be the highest. When a button is unset, if it is the highest number, you could start reading all the lower pin numbers than that, with the method described above, and if the button is lower it is ignored. . I'd be interested to see if the hardware method in the link above could be easily adapted to software but I'll leave that up to you :) Hope that helps! Edit: There may be much better ways to do this, as it's a very common requirement it wouldn't surprise me if there's a standardised method... Hopefully my method isn't too clumsy!

:D Correction: Yeh but if it's mounted in a case big enough for 64 filter boards I'm not sure it'll matter all that much ;) hehehe

Yeh but if it's mounted in a case big enough for 64 1/4" jacks I'm not sure it'll matter all that much ;)

You really should visit youtube ;)

Please don't crosspost :) how to adapt prioriy codifiers in the digital input of pic

Maybe I'm daft (OK definitely) but that may be the first time I've heard the word codifier :) Is there another word for that?

Sweet! Thanks man! PS I am going to reply soon ;) Edit: Search keywords... TK LCD font emulation screenshot screen shot picture image jpg manual document perl script TTF truetype HD44780 CLCD

TK has commented on this in the past but I never can find the post ::) IIRC the ICD won't work and main trick he uses is to send debugging info out via midi and/or by driving a pin and monitoring it on a scope... Kinda like breakpoints but, not :) It helps that TK is superhuman and writes perfectly functional code that works with no debugging, off the top of his head ;)

:)

http://www.pic101.com/mcgahee/ What a nice guy he is! :)

All correct :) MB64 should suit your needs.

Nah you might as well keep it, cause song chains ain't gonna happen, and most importantly you need to run MIOS Studio somewhere ;)

wannabe ;)

There's windows TTF and PS fonts of the HD44780 standard cgrom charset :) Grab the attachment from this post and rename to .zip and go nuts.

:oSomebody ban this blasphemous traitor! ;D Seriously though some good ideas :)

You bet :)