stryd_one

Cool. I'd move the Stop buttons above the play buttons (better to hit play by accident, than to hit stop by accident), and the encoder to the right side (easier to reach)

Cool :) That's not sent by MIOS, the midibox is just sending midi. The PC software that displays the MIDI messages for you, shows the Defined Controller Name, as per the MIDI specification.

Yer, parts are cheaper than labor. Unless you go to a third world country and have someone refurbish them in batches, and that's what happens to the dead ones they pull out, in our countries. Isn't it nice to know that you contributed to slave labour today? (Don't feel guilty, it's not like you have a choice. Just complain loudly)

Using the right flux would help for sure, but we don't know what the right flux is.... The thing I suggested was not to solder to the pads, it was to leave the existing legs soldered to the pads, and solder to the legs. If the legs are resisting your solder too, sand them back a bit. It's all metal under there :)

They are working perfectly. You are sending midi CC's to be used as a relative signal, not absolute - that means, it's not 0...127, it is +1 or -1 or +2 or -2 or +3 or -3, etc etc....The faster you turn, the more it increments or decrements. 64 would be 0; 65 is +1, 66 is +2; 63 is -1, 62 is -2, etc etc.....

You said: That is not really part of the application, it is part of MIOS. You should not edit this file. As you can see in SVN, There are only four files to this app, two if you don't count the readme and the makefile. From your description, what you have, is a 'distribution package'. This contains not only the application, but all of the other required files to build the application to run on MIOS. /include/asm/* are some of those files. A distribution package is intended for releasing a finished applicaton for distribution, and not for creating a new application as you have. This is because modifications are made which make it possible to build the application from the contents of the one .zip file, but they can make changing the application a little tricky. I'll come back to that..... Yes. that is how it's supposed to work. That file should not be edited, it is (as it says at the top of the file) a dummy table. It serves the purpose of providing an empty table, when no other table is provided. MIOS will look for the encoder table in your application files, if you provide the table it as it is shown on the wiki page, or as included in the example you have found. Almost, but not quite. If you are building a new app, you would do it using the mios_base package, and a fresh skeleton. The skeleton has a makefile in it, which you would normally edit, as you have done above. So... almost :) But not quite... I mentioned that distribution packages are not intended for creating new apps, and this is one reason why. You'll notice that the last line in the makefile (before you edited it), is: include makefile.orig That line, as it suggests, includes the contents of the file named makefile.orig, in this file. As it's name suggests, it is the original makefile, as it would have been in the application, prior to being converted into a distribution package. Because you have placed your edit below that line, the entirety of makefile.orig, which builds the app for you, will have completed, before your modification is reached. If you put the text before the 'include', then it still would not work, because that variable is overwritten in makefile.orig. You should edit makefile.orig..... or better yet, you should get rid of your current distribution package, download the mios_base package, and use the skeleton to create your new app. The question was not dummy, but not bothering to search the wiki was!

On a related note, this is the third time in two weeks I've seen someone edit MIOS files in an attempt to make their app work. The rule on this is pretty simple: You never have to change any part of MIOS. If you find yourself editing MIOS files, something has gone wrong, and it's time to post on the forum or visit the chat ;) The reason for this is simply because TK has already provided a way to change everything you need, at the application level. The encoder_tables_in_c page is a prime example of this.

hard to say, not knowing what the solder is... If for some bizarro reason you can't melt the solder... Cut the leads as close to the cap/as far from the board as possible, and solder your new cap onto the stumps. It's ugly, but it works...

LOL sweet! do it man!

I like your choice of workbench cover. Your homework for this class is to walk through the ghetto at night with a gold watch on :D

Yeh mate I got it. I was chatting with someone who was about to send their files also, so I was just waiting on those, so I can do them all at once. They'll be up, later today :)

Search the wiki for the word encoder. It's the first hit.

7912 +12V / 7812 -12V ? Is it wired that way too? Edit: maybe a version with the caps too would be good...

I think you made the right decision, good call. I spoke some more over in the new thread. Normally I'd merge these threads, but I think the announcement in a new thread is a good idea ;)

As you know I originally thought the DIN pintable should go on the DIN page, the DOUT pintable on the DOUT page. This is one of the concepts behind the new layout, is to avoid mixed up info.... but now that I look at it, I think that having the same table on two pages would suck. I think you took the best option there. Durisian, Is that cool with you? You've thought about this more than both of us combined ;) brilliant! one thing I changed was the page name, to din_dout_pin_list. Why? because when you type any of those words in the search box, it'll show up in the shortlist :) most important was adding the 'd' to 'dout', but i added the underscores to match the similar page names Good question... Would you like to suggest guidelines that you think would be smart? There are also the pretty boxes like on the current homepage, it would be good to figure out when to use them.. That didn't work out well, I have to scroll inside the boxes, to see the paragraphs. I think that for paragraphs, traditional line spacing is still best. Code snippets should use the code tag. you can also specify the code language, so we get code highlighting :) The examples shouldn't be there though - they would be duplicates of the examples that should be given on the application's page. That's just because it is a little different between apps. Great work man! *High five* 8) 8) 8)

Nice! Please do share some pics when you finish it off :)

You might not like nILS' questions, but you won't get far unless you answer them ;)

Sweet as! Thanks for all your help mate!

Yeh, nothing too exhaustive, just enough to catch anything really bad. In your case, I'd run one search only, for pages with "DIN" in the name. Well, actually I'd use the new wiki format... I'll come back to that. Did you ensure that any of the info on that page, was already in the wiki in another place? If you remove a page, naturaly you should ensure that you are not losing valuable info... Thanks!! Err, it helps if I give you a link! hahahaha sorry. I've put the forum link on the http://www.midibox.org/dokuwiki/doku.php?id=new_wiki_layout page now. Crap, you really have been reading. Dunno how you got so far, in such a short time. Anyway, you're very close. Correct namespace is :mbhp:module: there are module templates on the wikify page: http://www.midibox.org/dokuwiki/doku.php?id=wikify:template:module and as per the new layout pages (http://www.midibox.org/dokuwiki/doku.php?id=new_wiki_layout:mbhp) .... the din and dout page locations are already specified :) So... copy the contents of the template....click the link to the new din page.... click 'create this page', paste in the contents, paste in your pintable, enjoy :) As you can see, most of the wiki overhaul is just cut'n'paste work now. Durisian did the hard part for us :)

There aren't many who have tried this... It might take a while to get an answer :/ Hang in there mate!

Yeh, there are other issues too, we've just mentioned the big one. They ain't the easiest things to work with. But I'm not trying to talk you out of it, at least not yet, I'm just wondering why you feel you need to go that way. You say that you're not fixated on them, but you clearly are. Scroll up and re-read for proof - in a subtle way, you've been steered away from them by several people, but you keep going back there... I should point out to you that the only reason I mentioned the custom enclosure was that it is a requirement for the actuators you have been discussing, on the flexible circuit boards. This discussion is centered on the topic you have brought up, which is flexible circuit boards.. Possible doesn't always equate to wise ;) There's no point in me trying to talk you out of it, or help you with it, if I don't know why you're doing it/what you're trying to do... That's why I asked... If I do argue the point for 'normal' PCBs, and you do have some really good reason to do it, then I'm just gonna be plain out wrong. If I help you with flexible circuitry, and you don't have a good reason to use it, the difficulties you will (sorry but that's how learning works) encounter will almost surely put you off of DIY electronics. Even if you don't, you may expend all that effort to achieve the same result as gutting a bought keyboard, thereby wasting my time and yours. You said you've been thinking of a controller 'sleeve' which would be really fun :) Perhaps (even if you do need flexible PCBs for this, which I won't go into now) using flexible circuit boards on your first project would help to serve as a prototype of sorts... There's one small issue with that line of thinking, and you just read it: It's your first project. What you're kinda doing here is saying... Hmm... that cold blue liquid stuff with waves and fish in it, I think I'd like to build something to travel over that. I'm gonna make it 600 metres long, with a crew of 3000, and a flat top, so I can fly planes off it, and power it by mixing up heavy mineral that creates massive heat. :D Now there's nothing inherently wrong with building a nuclear powered aircraft carrier when you've never even built a canoe from a tree... It will just take a long time. You'll learn a lot, and it will be heaps of fun, and cost a fortune and take forever. And you may find when you're done that you'd have been just as happy with a canoe built from a tree :D Perhaps a way around this, would be to build something simple first, and work your way up from there.... Don't sweat it, lots of guys come here with grandiose concepts.... They generally fall into two categories: Those who never finish Those who finish, but only after working on it for a few years The vast majority fall into the former category... I wouldn't wish that upon you. Guess which one I am? :D And guess what? Over the years while working on my big project... I've ended up building a bunch of simple stuff. But the big one's still not done. Damnit. (It's a hell of a ride though!) While I'm fairly sure noone would argue the benefits of custom casing when you're able to get it for cheap... There is good reason why a few guys in this thread have given you advice that would negate the requirement for flexible circuitry........

This project is now available on SVN: GUISim_skeleton/

You got it! I posted about this the other day, I assumed (always bad to assume) that you read it :) If you are unfamiliar with what's going on there, be sure to read the forum thread I linked, it explains it all... There are MANY of them :( Lord only knows what that page is meant to be.... It should be removed. Jesus dude, I never blamed you for every bad wiki page there is! The situation here is this: There are LOTS of errors (as you have noticed) made by other people before you came along. There are so many in fact, that it can be difficult to find them all. Naturally, when you update the wiki, it makes sense to search for the information you are about to add, and look for duplicates. When you do this, you'll often find a mess left by someone else. if you just leave it there, then you've left a mess behind, and it could be a long time before someone else finds it - but, to clean up the mess, only takes a few mouse clicks (usually). So, even if someone else made the mess, it's still good for you to clean it up - if you don't do it....Who will? My point exactly :) what if that pintable already existed on some other page? This is why the correct procedure would be: - search for duplicate info - edit the pages Which usually turns out like this: - search for duplicate info - find related mess which will make it hard for newbies to find your doco - clean up that mess - edit the pages Champion! LMAO :D Hey, I was thinking that I should say to you... It seems that you're feeling a little defensive about the instructions and corrections I'm giving you - you shouldn't. Firstly, the golden rule of the wiki always stands - there are no permanent changes, so all additions are welcome. Even if they make a mess, or leave old mess behind. For example, I would prefer quintuplicate copies of your excellent pintable, compared with no updated pintable at all. Messy good doco > clean incomplete doco. Secondly, the only reason I'm telling you this stuff, is because you are one of the few people around here who are putting in this extra time for all of our benefit. I know that this extra work is not easy! It should not be taken lightly, and it is greatly appreciated. However, by following a few guidelines, mostly made by people who have gone before you and done the exact same things as you, you can gain even greater value from the effort you put in. These guidelines are just a way to achieve even greater value from all of your hard work - noone is 'telling you off', just boosting you up :)

LOL the last two rarely work out well around me.... In those quotes you took out of context: First time I said it's NOT our makefile Second time I said we do NOT need to modify our makefile Third time I was saying our makefile is GOOD. Why did I mention it a few times? Because you erroneously stated that this was a makefile related issue. It's not. No - any scripted method of calling SDCC would have suffered the same bugs. Makefile, shell script, batch file, hand-written command....whatever. In our particular case, it was the makefile calling SDCC, and that's what helped Raphael find the bug, so that's why he mentioned it. If you had appeared to have understood it, then I would not have attempted to explain it to you. When you said it was a makefile issue, it was clear that you did not understand. I was trying to help, look at the thanks I get... I'm just doing the "Yay, I got it right!" thing: Celebration; no accusation :) [me=stryd_one]hits this[/me] Stop being argumentative, I don't have the time for these discussions, even if you do. Hell, you have clearly shown that you have a high value to the DIY electronics/open source community, because you are willing to spend your time and effort and apply your abilities to help everyone around you, with things like wiki documents and source code and bug-fixing/reporting... Why waste such valuable time, arguing with me? I expected as much: 2.8.0 is the latest release build. The *.*.0 builds are usually very good, they are subjected to extensive testing prior to release. Yes, if it is valid syntax and does not work, then it's a bug, and should be reported. Is it still doing that with 2.8.0? It didn't for me.... Yaknow what shits me? You found the time to start a petty argument with me, but didn't even respond to the question I asked you: So, I'll ask again: How's it working? It would be nice to post "Thank Raphael, that works!" on sf.net :)

Hmm something occurred to me - have you, anywhere in your studio, done the 'i have an earth loop, so I'll cut the earth pin on this thing' trick?