Wilba

Most of the Super/Ultra bright LEDs will give maximum light output at 25mA or higher, but you can get a "normal" LED light output by dropping the current. They'll quite happily work at 1.5mA... i.e. take an ultra bright blue LED with a 3.5v forward voltage drop, with 5v supply, that's 1.5v across the resistor, divide by 1000 ohms, gives 1.5mA. They're still just visible when using a 10K resistor (that's 0.15mA!) This works because the Super/Ultra bright LEDs are in the 1000s of mcd and "normal" LEDs are maybe 150 mcd max. The 74HC595 has a max current output too (per pin), so even if you wanted to drive LEDs at 25mA, you probably couldn't. The other good thing about Super/Ultra bright LEDs... when you start multiplexing them (i.e. LED matrix) then the extra brightness offsets the fact they're only on for 1/8th the time. ;D

You can use extra (ultra) bright LEDs, you just need to increase the resistor from 200 ohms to 1K. But you probably won't find them smaller than 3mm.

First, let me say it's a nice design ;D and a great name (I used to eat out at an Indian restaurant called Sidhartha). Now I'll make suggestions... You need to check that there's enough space between the LCD and the buttons below it, and the encoder to the right. There's a lot of empty space to the left of the LCD, perhaps you could use a 2x40 character display with 10 buttons underneath? The label for envelope "rate" should be "depth" The label "aeg" is a bit obscure for me, but if it makes sense for you then use it, it's your box! Personally I'd just use "env". You can still use the five encoders as "assignable" encoders, even if you don't use a LED to indicate this... the "select" button can toggle through osc, aeg, misc, env and assign. I can help out with the coding if it's too hard for you. I think you just need to add an extra "mode" to the Osc Env/Misc/Assign modes... in theory it shouldn't be too much work. The missing SID buttons and "Link", "CC", "Edit" buttons will have extra uses in MB-SID v2. Even in MB-SID v1, you can only play a demo note or play a bassline sequence by holding down the SID button and the menu button (or from an incoming MIDI Note On event). You should also plan for getting more SIDs! So I would suggest you add the buttons/LEDs for SID1,2,3,4 and Link/CC/Edit to the design, and maybe wait until MB-SID v2 is officially released before making the panel ;D One final interesting point: The next (final) MB-SID v1 release (and MB-SID v2) will support buttons and LEDs (not encoders) in a matrix so you can use less DIN and DOUT modules. This means you are not so restricted with the number of buttons and LEDs you can have with just one DINx4 and one DOUTx4 module. I can explain it more later, but basically, with one DIN (8 inputs) and two DOUT (8+8 outputs) you can handle up to 64 LEDs and 64 buttons.

Maybe you accidentally burned "70" as the PIC ID. You can change the device ID with MIOS Studio to "70" and try uploading MIOS. Then upload the "change id" application. But it's probably best you work out how you got "70" as the ID. Tell us about your PIC burner hardware and what software you used to burn the PIC.

You can greatly reduce the cost by using a 1-stroke font. However, as I recently discovered, the thickness of the 0.2mmm and 0.4mm engraving tools come out larger than expected. I was told by Front Panel Express that this was partly due to the 1.5mm aluminium, but also just a limitation of the milling process, so you don't always get what you see in Front Panel Designer. I'm going to write up what I know in the wiki soon, but thought I'd mention it here cos it's relevant. As for material thickness, even though Front Panel Designer doesn't let you make big panels in 1.5mm thickness, you can explicitly request this. As far as I know, 1.5mm panels are quite stiff and perfect for my sized box (see http://www.midibox.org/dokuwiki/doku.php?id=wilba_mb_6582). You really need to decide what thickness suits your button shaft heights, encoders, LEDs, etc. i.e. how far behind the front panel will be the PCB with control surface components. The thickness of the panel determines how much pokes through. As for price, my front panel was $120, it's expensive but I guess I'm happy to pay for holes that are perfectly located and sized, even rectangular ones. I probably could have got it done without artwork and used lazertran, further reducing cost. Even with a drill press, it would still take me hours and not be as accurate, and I'd still have a rectangular hole to deal with, which is tricky.

Don't just "remember", go and look at the connection diagrams... You still need DOUTs for the LEDs that are not in the matrix.

They're charging that much for a SID because of the apparent scarcity... people building MB-SID or stocking their Prophet64 or HardSID are all driving the price up... especially 6581s which were up around $40 AU sometimes. I also have noticed the scarcity of the C64 stuff... I was able to pick up a few with missing keys or just the box (no PSU) for under $20 AU... eventually I gave up on salvaging and found new old stock SIDs, which I've sold on the forum some months ago. Getting one C64 isn't bad value if you're going to reuse the PSU, power socket, switch, case and the SID... but it could get expensive if you're trying to put together an 8xSID box like me ;D /tilted/, are you another Aussie MB-SID builder like stryd_one, dcer10 and myself?

- the matrix is primarily used to select which modulators (envelopes/LFOs) modulate which parameters (pitch/pulsewidth/filter cutoff), but also can be used as a meter (shows bars representing current depth of modulators). It is a lot more ergonomic to use than the menus, and if you have the space on your panel then you should consider putting it in. - the matrix uses two "DOUT"s, so you still need 2 DOUTx4 modules, with two "DOUT"s unused. It needs 8+7 DIN input pins, you still need 7 DINs, so you need 2 DINx4 modules. - try to get the 24LC512, they are about the same price and store twice as much. DIP and SMD just describe the package, one is dual inline (through-hole) the other is surface mount, will be very small and much harder to solder.

Can I suggest that entries be done via the MIDIbox wiki? We can have a main competition page, where anyone can add a link to their entry under the category heading. People can be encouraged to use the wiki to create an entry page, but if people want to link to their own website or just a photo collection like Flickr, they could do that too. Maybe this way, at the end of the competition, there'll be a lot of wiki pages about people's various MIDIboxes, which could go into the gallery. I wouldn't like people prevented from voting just because they don't post much, or at all... if people know about the competition, they are MIDIbox fans of some sort, so let them vote.

My list was just a suggestion... less is best probably... "Best pro-looking MIDIbox" - where those boxes with awesome panels and custom layouts compete. "Best DIY-looking MIDIbox" - it's obviously DIY, but functional and well constructed and looks cool. "Best recycled MIDIbox" - recycled C64 cases in this category, I guess, but also people who recycle things for their case, knobs, buttons, etc. "Best customization/extension" - covers those who did hardware and software changes to an existing app, i.e. redesigned control surface, synth with built-in keyboard, or a synth with extra effects hardware. "Best MIDIfication" - keyboard or organ conversions, or just adding knobs to something else. "Best user application" - a totally new application, not just extensions to the existing ones. "Best documentation effort".

I also vote C. I like the competition idea, without any prizes. It's hard to put all the MIDIboxes that exist into a single "best box" category, how do you compare an immaculate, pro-looking controller with an obviously DIY one? One has aesthetic appeal, the other has junkbox, recycled chic. I'm actually more interested in getting as many people as possible who have ever build a MIDIbox to take some good photos (fuzzy webcam images do not count as photos) inside and out and write a little bit about their MIDIbox experience. Then hand out some recognition awards like: "Best panel design" award "Best reuse of an enclosure" award "Best recycled enclosure" award "Best pro-looking" award "Best DIY-looking" award "Most internal wiring" award "Neatest internal wiring" award "Best internal construction" award "Best customization/extensions" award "Best keyboard/organ conversion" award "Best integration into existing hardware" award etc, in addition to "Best newbie doco" and "Best user app" Maybe a competition might inspire a few more people to show off what they have done.

I don't understand your questions... are you asking me about the encoders OR knobs I used on my MB-SID?

What is a "Secret Chip midiBox" ??? There's a difference between a crystal and a crystal oscillator. A crystal is (often) a two-pin component in a metal can. The crystal oscillator in the OPL3 module is (often) a four-pin component in a metal can, and contains the crystal and other components so it will output a pulse waveform. Unfortunately, in the sound cards I have, they have 14.318 crystals, not crystal oscillators, another chip on the card is using the crystal to generate the pulses. There are crystal oscillators on the sound cards but they're the wrong frequency.

You're totally underestimating the complexity of such a tool... and how it must integrate with the rest of your source code and add the required code when you click and type a bit of text. Even sophisticated IDEs like Visual Studio only do the bare minimum for you, and you still have to go and edit the code manually and make it do what you really want. The problem is, coding for a microcontroller in ASM (or very, very lightweight C!) requires code that would be considered ugly hacking in higher-level languages like C++ and Java... all variables being global, no use of classes, storing state in a couple of bits of one memory address instead of a nice set of named variables. The code for one menu item is in a few places, because its grouped by function, and it has to be that way, grouping it the other way would involve a lot of extra code. TK has put a lot of work into generalizing things, hence the use of tables to "connect" a button's DIN pins with a function to call if it's pressed. So in your example of making "Select 1" do something different, here's how you could have worked it out: In cs_menu_io_tables.inc: DIN_ENTRY CS_MENU_BUTTON_Sel1, 1, 7 Now do a "find in files" with your favourite text editor for the function CS_MENU_BUTTON_Sel1. There it is, in cs_benu_buttons.inc: CS_MENU_BUTTON_Sel1 ;; select button #1, set cursor to 1st position movlw 0x00 ;; rgoto CS_MENU_BUTTON_Select_Cont CS_MENU_BUTTON_Select_Cont ;; do nothing if button has been depressed IFSET MIOS_PARAMETER2, 0, return ;; set cursor to: CS_MENU_PAGE_OFFSET + number in WREG addwf CS_MENU_PAGE_OFFSET, W ;; branch to the CS_MENU_Select function goto CS_MENU_Select [/code] Note the commented-out "rgoto CS_MENU_BUTTON_Select_Cont", it "drops-down" into that function. So, depending on which select button is pressed, it sets the number of the button in W register, which is then added to the current offset into the menu (you can scroll the menus, so Select 1 isn't always the first displayed menu item), and then calls CS_MENU_Select. Go have a look at that then... In cs_menu.inc [code] CS_MENU_Select ;; if in name editing mode, branch to CS_MENU_Select_NameFunc IFSET CS_STAT, CS_STAT_MODIFY_NAME, rgoto CS_MENU_Select_NameFunc ;; if in main page (CS_MENU[7] set), branch to root menu IFSET CS_MENU, 7, goto CS_MENU_EXEC_GoToRoot ;; store new position in CS_MENU_CURSOR_POS movwf CS_MENU_CURSOR_POS ;; store cursor pos in CS_MENU_PARAMETER_L movwf CS_MENU_PARAMETER_L ;; clear CS_SELECT_CTR (so that new message appears immediately) clrf CS_SELECT_CTR ;; now request a display update so that we see the new parameter on screen bsf CS_STAT, CS_STAT_DISPLAY_UPDATE_REQ ; (see cs_menu.inc) ;; clear counter so that cs_menu_timer.inc counts from zero and the menu entry is marked for a short time clrf CS_CURSOR_CTR ;; clear "CS_STAT_CURSOR_FLASH" bit (see cs_menu.inc for the handling) bcf CS_STAT, CS_STAT_CURSOR_FLASH ;; leave function if cursor pos >= max entries movf CS_MENU_ENTRIES, W IFGEQ CS_MENU_CURSOR_POS, ACCESS, return ;; branch to EXEC handler ;; get pointer to entry which has been selected rcall CS_MENU_Hlp_GetCursorPosEntry ;; get handler IDs rcall CS_MENU_GetHandlerIDs ;; EXEC ID in MIOS_PARAMETER2 movf MIOS_PARAMETER2, W rgoto CS_MENU_EXEC_Handler Oh, lots of code! But the interesting thing is, in the second line of code is: ;; if in main page (CS_MENU[7] set), branch to root menu IFSET CS_MENU, 7, goto CS_MENU_EXEC_GoToRoot [/code] So the comment tells you it's testing if you're in the main page and to do something different. So you can copy how that's done and put it in your button handler, so that Select 2 to Select 5 can work as an "alias" to SID 1 to SID 4 buttons, like I showed you. Look at the rest of the code there... it's actually quite generalized, there's no references to exactly which menu it is showing, and there's no code there to draw the menu. This is because handling a button or encoder event happens at one time of the MIOS event loop, and writing to the display happens at another. A flag is set to get the display updated, and in that event handler, it works out what it should write to the display. Just look at how neat it is. It looks up the menu tables to work out what it should do, so the menus themselves are already generalized into separate tables elsewhere. And here's the elsewhere, for example, see how the Filter menu is handled. In cs_menu_tables.inc: [code] CS_MENU_ENTRY CS_MENU_FIL, "FIL", 0x00, PRINT_NOP, EXEC_MENU, R2PP2R_NOP One line to define the "menu" as it appears in the "root menu"... labelled "FIL", given an ID called CS_MENU_FIL. Futher on, some code to define what's in the filter menu: ; ========================================================================== ; The filter menu ; ========================================================================== CS_MENU_TABLE_FIL db (CS_MENU_TABLE_FIL_End-CS_MENU_TABLE_FIL)/CS_MENU_ENTRY_LEN, 0x00 ;; Register (00=dummy) |<->| max print ix exec ix parameter transfer CS_MENU_ENTRY CS_SID_FILTER_CHANNELS, "Chn", 0x07, PRINT_FILTER_CHN, EXEC_SELPAR, R2PP2R_FILTER_CHN CS_MENU_ENTRY CS_SID_FILTER_CUTOFF, "Cut", 0x7f, PRINT_DEC, EXEC_SELPAR, R2PP2R_CC CS_MENU_ENTRY CS_SID_FILTER_RESONANCE, "Res", 0x7f, PRINT_DEC, EXEC_SELPAR, R2PP2R_CC CS_MENU_ENTRY CS_SID_SUSKEY, "KTr", 0x3f, PRINT_KTR, EXEC_SELPAR, R2PP2R_KTR CS_MENU_ENTRY CS_SID_FILTER_MODE, "Mod", 0x07, PRINT_FILTER_MOD, EXEC_SELPAR, R2PP2R_FILTER_MOD CS_MENU_ENTRY CS_SID_FILTER_CHANNELS, "Ext", 0x01, PRINT_FILTER_EXT, EXEC_TOGPAR, R2PP2R_FILTER_EXT CS_MENU_ENTRY CS_SID_FILTER_MODE, "3Of", 0x01, PRINT_FILTER_3OF, EXEC_TOGPAR, R2PP2R_FILTER_3OF CS_MENU_TABLE_FIL_End [/code] Another nice table, each line defines a menu item, a "register" (used to identify a parameter in the patch) with text for that menu item, the max value and which functions to handle the printing, selecting and transferring of the parameter to/from the patch. That is really generalized, and this generalization not only avoids a lot of repeated code for every possible parameter, it makes it really easy to extend, if you wanted to add new parameters. The point of going into all this detail is to show you exactly what you're suggesting could be replaced (or just edited easier) with a visual tool to make life easier, as well as give you a quick overview of the code should you want to make your own menus. I'm also suggesting that once you learn a bit more ASM and work out how this code all works, then you'll discover that it really isn't that hard to change it to do what you want, be that make a new application or just make changes to the MB-SID application.

I've updated the panel previews to the final version, what I've already ordered ;D Note: none of the differences to the original design are planned and official MB-SID V2 features! They're just what I would like in my MB-SID, and what I will code myself. In case anyone is interested, I'll list the differences to the V1 "step C" control surface: "Link" button replaced with "Sync". This will be my global toggle between internal BPM and sync to external MIDI clock. I want to easily switch between playing a bassline in time with the external sequencer, or during development when I just want to play it without the external sequencer running. TK agrees this is a Good Idea so I might not have to code this feature myself ;) BTW, the "Link" feature is obsolete with proposed hardware changes, using PIC18F4685 and a CAN bus to the slaves. "Play" button: this will replace the "SID button + Menu button" to trigger playing a note on the SIDs. Extra buttons around menu encoder: The four to the right of the display I might use for fast selecting of a row on the display... maybe for the wavetable or sequencer pages. The buttons above and below the encoder are the "Menu" button and an undefined "extra" button for some feature I might want later. Matrix mode select button and LEDs: Pretty self-explanatory, switches matrix into the other modes, V1 lets you switch between the mod matrix and metering mode, and I've expanded that to the proposed extra matrix modes. The names "Mod 1" and "Mod 2" are generic on purpose. Filter Ext-In button: Since I plan to use the feedback idea (routing SID output through a pot into SID input), I wanted an easy way to toggle filtering of external in. Missing "O3" LED in filter section: If I had the space space, I would put it in, with its own button. "Misc" mode in Envelope section: A second set of parameters for envelopes, as described in the V2 wishlist. "Curve" buttons/LEDs: Originally this was "Curve Assign" like the V1 feature (but missing from the "step C" panel) so I added it. Now it might not be needed if there's a separate curve parameter per envelope phase! So it might be used for another purpose... perhaps to multi-select envelope phases and let the Curve knob change those curve parameters. "Ramp" LFO waveform: I always wanted a ramp. I'll code it myself if I have to! The rear panel has a few "extras" too: Mixed output: Above the power switch/LED is a mixed audio output. If there are no plugs in the SID 1-4 audio jacks, the audio gets mixed through some 10K resistors. It's not that elegant a solution, but good enough for the times I just want to listen through headphones or plug it into someone else's amp or something. Expansion port: In case I ever get around to using external filters or external analog inputs (joysticks, ribbon controller) or whatever else I can dream up, I can wire it through this 25 pin sub-D. I think I'll make it female like a printer port. Four "feedback" knobs: The holes above the audio jacks will host four dual-gang 500K log pots, which attenuate the SID audio out on its way back into the SID. These can give effects like a resonance boost, self-oscillating filter, or distortion. They're log pots, so I still have to work out which way round they should go! Fan hole: I'm sticking a 40mm fan in that hole. It's half-bling and half-functional... a little breeze inside that small box might just prevent SID death on a 40ºC summer day.

I've updated the panel previews to the final version, what I've already ordered ;D Note: none of the differences to the original design are planned and official MB-SID V2 features! They're just what I would like in my MB-SID, and what I will code myself.

I don't know if a "visual tool" is feasable... there are similar things in application software development, like editors for menus and dialogs and such, that ultimately generate source files that get compiled into the application. So while there's nothing impossible about doing the same thing for a MIOS app, it's a lot of work to build such a tool. What perhaps you are wanting is a code skeleton demonstrating how to code a simple menu system like MB-SID. Imagine you take the menu code out of MB-SID and generalize it so it's not specific to MB-SID... then it would be easier to see how the buttons and menu encoder handlers work, how the "selected" parameter is determined, shown on the LCD, changed by the menu encoder handler, etc. Then you'd see how to edit the ASM (or C) code to do what you want, and drop it into whatever application you're working on. That's time-saving enough, and cuts down on the not-so-fun bits. Ultimately, if you're going to write a MIOS application to do something, you'll have enough coding ability to do the menus too, either from scratch or by coping from example.... just like I was able to help you out before by knowing how to copy a line from here and stick it there.

OK, I cut-n-pasted some code that should work, but it's totally untested ;D In the handler for Select 2 through Select 5, if you're in the "main" menu (shows patch name, selected SIDs, etc.) then redirect to the SID 1 though SID 4 button handlers. This might also allow you to hold down one or more of these "SID" buttons and then press the "menu" button (labeled "Esc" on your panel) to play the SIDs. NOTE: playing a note on one SID will play all SIDs using the same MIDI channel, even if the display doesn't show this. And here's the code (I assume you know where it goes ;) ): CS_MENU_BUTTON_Sel5 ;; if in main menu, select SID #4 IFSET CS_MENU, 7, rgoto CS_MENU_BUTTON_SID4 ;; select button #5, set cursor to 5th position movlw 0x04 rgoto CS_MENU_BUTTON_Select_Cont CS_MENU_BUTTON_Sel4 ;; if in main menu, select SID #3 IFSET CS_MENU, 7, rgoto CS_MENU_BUTTON_SID3 ;; select button #4, set cursor to 4th position movlw 0x03 rgoto CS_MENU_BUTTON_Select_Cont CS_MENU_BUTTON_Sel3 ;; if in main menu, select SID #2 IFSET CS_MENU, 7, rgoto CS_MENU_BUTTON_SID2 ;; select button #3, set cursor to 3rd position movlw 0x02 rgoto CS_MENU_BUTTON_Select_Cont CS_MENU_BUTTON_Sel2 ;; if in main menu, select SID #1 IFSET CS_MENU, 7, rgoto CS_MENU_BUTTON_SID1 ;; select button #2, set cursor to 2nd position movlw 0x01 rgoto CS_MENU_BUTTON_Select_Cont CS_MENU_BUTTON_Sel1 ;; select button #1, set cursor to 1st position movlw 0x00 ;; rgoto CS_MENU_BUTTON_Select_Cont [/code] (minor edit, made it work like you were trying to make it work, with Select 2 to 5, nice idea...)

I think it is already in MB-SEQ V3, but it's not officially released yet.

When the red and green are both on, the light is yellow or orange. That's the third colour in the demo. I've only got the idea at the moment, that when I build my MB-SEQ, I'll use RGB LEDs and write a little bit of code to handle the extra LED colour. For now, there's no problem for you to buy RGB LEDs and only use two of the LED colours, if you choose red and green it will work exactly like the demo, then at a later stage add the third LED colour if someone writes the code for it ;)

You mean the button and LED matrix for MB-SEQ V3? http://www.ucapps.de/mbhp/button_duoled_matrix.pdf These RGB Leds are "common cathode". That means the red, green and blue LEDs are joined together at their cathodes, the pointy end of the arrow symbol. The Button/Duo LED matrix uses two-colour (Red/Green) LEDs, also common cathode. So you could use RGB LEDs and choose to use the Red/Green, the Red/Blue or the Blue/Green LEDs. Or you could add another shift register to control all three colours, and change the code to support the extra shift register. That's my plan, by the way ;D

Which PIC do you need? I have a few spare, I can preprogram as well.

OK, back on topic, sort of... I actually encourage and applaud TK's decision to let people know ahead of time what the future hardware might be, and then change his mind for the better of the project, even if it means us "experienced users" he speaks of now have chips they don't need. ;D This CAN network stuff is brilliant, a much nicer design than using MIDI. If it's too hard getting a PIC18F4685, then just stick with PIC18F452. There's not much advantage to upgrade now, other than avoiding the cost of a new chip in six months.

I'm assuming you mean can you leave unused output pins open and not connected to anything, and the answer is yes, there's no problem doing that.

I already proposed some kind of benchmarks to be defined, there wasn't much interest. When testing SIDs for sale, I used a poly patch to test each oscillator works (three note chord, basically), and then changed the patch to one that used the filter and tweaked cutoff. So it was really testing by ear, if it sounded the same as the last SID I tested. As far as filters being broken, from experience, when broken they can cause the SID audio output to mute when you turn on the filter, and sometimes stay muted even if you turn it off. There also might be loud popping when you change the filter mode. I suppose a test app might be useful, but it's not that much more effort to just listen to a few patches. Maybe a recording of a filter sweep of one of the preset patches might be handy for comparison.