Jump to content

stryd_one

Frequent Writer
  • Posts

    8,840
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by stryd_one

  1. In the meantime, I'll delete for you (immediately, no waiting) ... Come to the chatroom mate :)
  2. Now that I think about it, you're right. It should be :home: . Agreed again. Hot tip: Firefox extension "CoLT". Allows you to do cool stuff like copy links and reformat them for dokuwiki or bbcode for the forum. Homepage: http://www.borngeek.com/firefox/colt/ Dokuwiki format to configure it for our wiki: [[%U|%T]] This extension saves me a LOT of editing posts.
  3. Heya mate. Well the midisport is one of the ones the guys here recommend... If you have a physical cable (not a virtual loopback like hubi's) going out of the ms1x1, and looping back to the ms1x1's input, then you should receive exactly what you send.... That sounds like a feedback loop. Perhaps you have the PC (mios studio or hubis or something) setup to echo it's input to it's output. Then, you have input --> output --> input --> output --> etc, forever. That's no good. Let's get the midi interface to behave first :) Perhaps, if the hints above don't help, you could upload a screenshot of your mios studio routing page?
  4. That systemuses , as do TK's, the strategy ultra mentioned of holding a flag or flags which tell the update function what to do. Although it should work on SDCC with minimal changes, it's probably better to use something a bit lighter. You can use switch statements to call functions, and it'll build a nice fast jumptable.
  5. Right, so your SRIO is good, your LED is not connected to pin 0. I think I know what this is, and if you look on the forum for posts about the SRIO chain, you'll find one from this week. It's best not to edit a post once it's been replied to, makes things a bit confusing. I had to re-read your whole post again, to find out what had changed, and it was all for two lines. Better to just post the two lines of update in a new post ;)
  6. Right now, because there is no defined structure, pages get added and removed and info moved....so we already have that problem ;) But the structure could be flat or heirachical, whatever works best. I'll say before I go on, that I'm totally feeling where you're coming from; but I think that you're overestimating the health of the wiki now, and the difficulty of namespace linking. That's what the templates are for - the user doesn't have to think about it, just go to the appropriate section and paste in a template. Finding the appropriate section is a no-brainer thanks to the namespace listing, and the rest of that section (:wiki_layout namespace) which is there specifically to tell names how to do stuff. On top of that, the template already has a space allocated for pretty much everything i could think of documenting, so the need to create new pages would be rare. Not from a browsing perspective, but from a filing perspective it's heaps better. Take a look at the files on the wiki now... imagine that all those files were in a flat structure :/ It also highlights the need for a naming convention for the wiki regardless of flat vs hierachical structure. What a mess... That was the first specification we had - it had to work like how users keep requesting it, with a start-end approach (of course you can always jump to the middle via the search engine) That's a great example of one of the problems with the current structure. Banksticks aren't mb6582 specific, so info about them should not be filed under the 6582 pages. The link would be absolute, like /MBHP/modules/bankstick., no need to step back with ../../ well maybe yeh. but then what if we need another page about banksticks, say, mb6582 related (seeing as it's a different board)... Would it's new name follow a flat naming convention or a hierarchical namespace tree? Either way, it's something that the name has to learn. But it's not rocket science, it's already laid out in the wiki where it would go. Agreed 1000%. Ease of use is really important. Hindrance to documentation would could turn the 5 volunteers we have into 2. That's bad. Yeh but there's three times as much work going into maintaining it, as there is adding content :( That's a problem that requires a structure to follow, but it's nothing to do with flat/heirarchical approaches. Then you aren't cleaning up as much as me ;) I think that flat vs heirarchical is debateable, but the need for structure on that wiki is unquestionable IMO. Seen our THREE FAQs? hehehehe Sure the info is there, but it's a mess. Thing is, on the very rare occasion that someone needs to make a new page, they will need to spend some time to maintain a healthy wiki, and that will either mean learning a namespace (tree view, familiar to newbies) or a naming schema (:root:MBHP:modules:AIN vs root_mbhp_modules_AIN). But yeh, that'd be rare.
  7. Use smart mode and wait for request, always. It sounds like you're doing it wrong, you don't wait for anything. midibox OFF mios studio... smart mode ON wait for request ON select your hex file click the start upload button mios studio says it's waiting for the upload request turn on midibox (at which point it will send the upload request) everything should upload automatically Yeh, the two bytes may not be (weren't) a valid midi message. Check out the brainwashing centre. Anyway your core seems healthy :) That's SRSet not PinSet - it sets all 8 pins on the SR in one go, 0xff == 11111111 == all on :) That code does that for all your SRs (you have it configured for a single DOUTx4 module so 4 SRs, and no DINs, at the moment)
  8. All input is warmly welcomed. Not much point fixing the wiki if everyone hates it :D There is a page explaining the namespaces, as part of the other documentation on how to document stuff on the wiki :) The namespaces : in the links basically work the same way as a / in a filesystem. Similarly, it's especially handy when it comes to storing images and downloads on the pages... But if it's a problem then it should be considered....What was the nuisance you had with it?
  9. Sounds like a fun project. Don't worry about opening threads to ask for help, that's what the forum is for! Did you use smart mode and wait for upload request when you loaded mios? Try it again, anyway. If your bootloader is a bit kooky, it's possible that it starts mios and then dies. If you have it send a midi note when it receives one, does it work? I can tell you've had a look around, don't forget the Troubleshooting section of the Download page on ucapps.de. The SRIO interconnection test could help. Assuming your SR chain is working after that, you might like to try this: for (i = 1; i < MIOS_SRIO_NumberGet(); i++) { MIOS_DOUT_SRSet(i,0xff); } Should light em all up, in case you've got the led on the wrong pins.... Maybe the LED is the wrong way around? On that note, I didn't quite understand your description of the wiring, but theres a simple answer to that - make it match the schematics. If it does, it will work :)
  10. It's certainly OK - nay, encouraged, to post the link here. It's a really good blog, will be great for new members to read that one :) It's just a real shame you didn't document it on the wiki :( Offsite documentation goes missing, cannot be updated, gets out of date and confuses people, etc etc etc....
  11. Well yeh... otherwise we can't have old and new pages existing simultaneously. Makes it hard to do new pages. Well, there would be two of everything, an empty one as the design guideline: :wiki_layout:community:etc and the real one: :root:community:etc That's where the problem comes in - some of it needs to stay, some needs to go; some needs to be duplicated, some will be replaced.... and the big problem with that, aside from the difficulty in creating the pages, is that once the overhauled pages are in-place, we'll have no guideline left over for future reference - which will have the effect that the wiki's content will slowly drift away from your design over time. Best to keep the layout pages permanently, and have the real content coexisting alongside it. this has volunteered for that job. Legend.
  12. I think you're on fire man. If durisian agrees with your plan, I say go for it.
  13. All done, and some extra to follow up on your other post. great stuff man. Sorry for the wait! Edit: I put the root namespace there because of your other post... perhaps I misunderstood...We should continue this conversation over in that thread... (or the chatroom!)
  14. Yeh, that was made wih the intention of the new_wiki_namespace being removed one day, I like your idea of keeping it around much better...It's a big job, I think you must be addicted to wiki or something, but it's great stuff!!
  15. Yeh it was a stumbling block for me too! honestly, the only reason i didnt say something was that i didnt expect someone to invest that much time... and then..... Well shiiit, awesome! There's only one thing I don't like: "new" wiki layout. It won't be "new" for long, and a couple yeas from now when we do a new wiki layout, what will we call that? The new new wiki layout? hehehe I think the new_wiki_layout pages need to go into a new namespace called wiki_layout or something. on a related note, the user spaces was a bit tricky, and even marked with a FIXME, so I think I have a solution... Each user gets a namespace to store their files, like so :root:community:this:* They can create namespaces as required :root:community:this:midi_mapper:boards_wiring.jpg That way, whether the images are linked from the user_gallery page, or from the projects page (for finished projects), or from the communty page (for projects in progress), the files don't have to be moved around. And yes, that link is real, sorry for the long wait!!
  16. Stupid work. Who needs money anyway... oh wait.... nevermind...OK I'm back, and I'm doing it NOW! Sorry! I really am trying!
  17. You're both being impatient. The thing to realise here, is that nobody posts here when they come to me in the chatroom and I upload the files within 5 minutes, nobody comments on the current solution when it works. I didn't want to imply that either, that is not the plan. Write perms on the wiki are, at present, granted by adding users into the 'Frequent Writers' group. This doesn't just give you access to upload files to the wiki, but some other things. It's a tricky situation, because while it makes perfect sense to give upload perms on the wiki to a guy who is working hard at it like you are, it may not make sense to apply the other permissions which are granted by making you a member of this group. What I was implying when I mentioned twinnie, is that there will always be a degree of human interaction required to grant write access to the wiki. Whether that human interaction is twin-x adding you to the group, or whether it is me uploading the files for you, it's still possible that sometimes either one of us will have unexpected troubles in our personal life which will prevent us from doing that straight away. So, sometimes if you are unlucky, it will take me two or three days to find time to upload the files, sometimes if you are unlucky it might take twin-x two or three days to add you to the group, etc... that is speaking hypothetically, because adding someone to that group is by invitation only, not by request, and also because twinnie is pretty busy with maintaining this website in his sapre time, which is why we have this email address to prevent him from having extra workload of adding and removing people to the wiki permissions. Also, I'm not the only one who can upload for you - anyone who is a 'frequent writer' can do it - I've setup the gmail address to make it easy for people to contact us, but at present, I'm the only one who monitors the emails. It's the down-side of a volunteer-based support arrangement like we have here, that we don't all have as much time to give to midibox as we would like :( I'm sorry I ignored your request for write access, but it is because I didn't want to offend you by saying that adding you to the group would not be possible until you are invited, and that is unlikely as you're kinda new... But yeh, long story short, normally I am pretty quick to upload... Just, sometimes, it f*** up, and I apologise for the inconvenience, but I'm doing all I can... Annnnd damnit my on-call phone just rang, so now I have to dial in to work and there will be more delays. F*** IT@!!!
  18. Love your work man. Yes it is confusing. I'll explain in a couple hours, after I do this job interview and upload your files ;)
  19. It works just fine, you're just being impatient. It normally doesn't take this long, usually they're up within an hour or two, there have been extenuating circumstances. I'm too busy to explain now, but I'll come back soon. You'd have to wait for Twin-X to add your permissions anyway, so either way, it will require human interaction. Just, sometimes we get busy...
  20. No sweat sasha, keep us posted. I can give you a hand with merging the play/pause button if you like.
×
×
  • Create New...