Durisian

hey neb - objection noted :D My biggest problem is that I refer to wiki as a quick reference tool. But it's more like a long and painful reference tool - as I pore through pages of data that may or may not have the information I need, and sometimes find conflicting info as procedures etc have been changed. I did consider that creating rules would scare documentors, but the lack of rules is exactly what makes the wiki a mess. I think asking documentors to learn a namespace structure (and really that's the only thing you need to learn) is a small price for good documentation. We will make sure it's is very clear when the time comes. As stryd mentioned the templates will make it easy - hmmm, I should add all the module links to the project template so you delete unwanted ones - rather than add the ones you need. I hope that with these templates it will encourage people to write the doco's - the hard part is already done, you just write about the specifics of your project. As for the big stuff like - svn, toolchains and blah. All (i think) is listed in the new_wiki_layout, as for new stuff, well - There are only a handful of people who write this, mostly with far bigger brains than mine - i'm sure you guys can handle it :D edit: There is the matter of the forum links etc - Did twinny install the redirect plugin?

Is [root] really required? (perhaps I've missed something) - given that no namespace is the root, it's kind of saying root:baze:community:etc:etc Yeah, I created new_wiki_layout as temp namespace as a sounding board for ideas, which is now the place where the links for new pages are created (to make it easier for anyone to chip in) - most of the data in this namespace will be removed, but bits need to copied to the new wiki, such as the wikify stuff. So if a [root] namespace is required, we need to make sure the links in the new_wiki_layout are updated to point at the right place.

That's great - One of the aims is to have 1 place for the data. So when things change we don't end up with a jumble of old and new info.

Agreed... 4 x VGA Displays is not too big! :D

yeah - do it Phil!

Fonebone: But I guess this was your hd147 not outputing messages, rather than a pedalboard issue, I'll do some more research into it. But Given that it won't output it's settings as standard midi messages - it looks like the only way you'll get the leds to light up accordingly is to program the appropriate CC's in as rig control patches (very boring). And use rig control rather than direct program changes to control your hd147.

That stuff is awesome Jim! I'm flat out till Jan so won't be doing much work on this till then. A large chunk of 'laying out' has been done - and just needs hands to copy/compile info in to the right places. Anyone/Everyone is welcome to just jump in!

Welcome Altech! Firstly - I have ask - isn't this your roommates project?? :D Your best bet is to program in C. SDCC and the MIOS wrapper take care of the asm'ing. A C skeleton is available to get you started (find it in the svn repository or MIOS base package) It pretty much speaks for itself. Programming in C is pretty easy to help for. I just use google - eg "for loop C" and get a lot of pages detailing syntax and usage check out the C functions reference as well. You'll see that turning DOUT pins on and off is very simple.

Hi Guys Just registering my interest in the project - this would be awesome. I'm afraid I don't think I can help much, but will jump in where I can In terms of features, I think DMX input would be great - it would pave the way for all sorts of things to be controlled via a lighting console. Other projects that do this I've seen are somewhat limited, and very expensive. Could also use slaved cores rather than using IIC... just a thought

Damn! 1 Australian Dollar = 0.516375 Euros I love the economy!

wait.... MIDI_MERGER needs to be off! :-[

that kinda sux pbx file looks fine What info does the 147 spit out when send a program change event via midi? I'll have another look through the line6 manual (I'm also flat out with work till the end of the year) Did you get midi in to your pedal board working?

No MIDI at all! ??? make sure you've enabled midi input. Could also be the master bankstick merger disable feature set pbx_config.h like this: #define ENABLE_MIDI_IN 1 // 1 = yes 0 = no #define MIDI_MERGER 1 // 0 = off 1 = on #define MIDI_MERGER_DISABLE_MASTER 0 // 0 = enabled 1 = disabled - If set will disable forwarding of events on the master bankstick channel Can you post your pbx file again?

oh, sweet... this looks familiar http://www.midibox.org/forum/index.php/topic,11300.msg89130.html#msg89130

Compile issue: line 1253 should be suspend_LCD(); it was: suspend_lcd(); Beats me why mine compiled and yours didn't. Got me worried now, because mine should have spat out that error too. updated, give it a crack MIOS studio issue.... to be honest, beats me. Have you updated java or something recently, anything you've changed since you last tried to use MIOS studio. can you upload a basic app - like din buttons from the download section on ucapps? you can also try re-uploading MIOS 1.9f. no idea if that will help

Great sounds like i'm winning! :( I'll try re-installing when I get home. Can you list the errors? ------ When you get MIOS Studio errors like that: turn off your pedal board check the 'wait for upload request' box click start turn it on

hey, yeah... the chat let me find another can first ;D Layout Strucure Still a ton of stuff missing, but my brain hurts

sure am! I've been working on a overall layout using a spreadsheet. The hardest part I'm finding is a way to keep it simple - but still keep the more advanced (and idea) documentation easy to find.

updated. -Pedal Box Programming now enabled... oops -Bug with LCD returning to show wrong current program after AIN fixed -LCD will suspend for a short period after sending a program change

Thanks Twin.... oooo, upgrades. I tell myself everyday that when I get up, i'm going to run round the block a few times, do some sit ups and then some weights... it never happens ;D I think there will be some time before anything drastic happens I think you've missed a point - The template would be the guidline for all those. So there would be 'how to build a [mbdm, mblc, etc]' sections that are updated to follow the template. The concept being all project docos will follow the same format. A generic guide becomes almost irrelevant. However a basic run down of links at the top level would be handy for quick reference.

How to build a ... module template Getting Started -Where to buy PCB's - link -How to etch - link -Where to buy parts - link -Tools Required - link -Soldering - link -Pin out list -.brd file -Schematic Building it -List of parts -Building instructions -link out to terminating cables, etc -Special Instructions links - (like smd soldering) -Testing -Common issues

mmmmmmmmmm... worms ok.... so... ... yeah, worms I think your right, we need an overview of the whole thing before it can really be cleaned up maybe we need a 'how to build a ...' template Intro -All about it, what it does and blah Skills / Equipment Required Tools - link Soldering - link Harware -list of modules - with links to how to build them -list of pots, buttons, faders and blah - suggestions on good parts and where to buy them + how to hool them up - links -Connection diagrams - link if needed -Enclosure ideas - link to case construction tips? / provide space to encourage other users to wikify their case designs Software -burning bootloader - link -Core Tools - link -MIOS Studio and Additional tools - link. -The app and modification instructions Usage manual link The template can can reside in the wiki, for people to utilise on new projects -------------- that should get everyone off the ground. App development is a-whole-nother story. I don't think the blurred line can be completly removed - but can be made much more in focus. Perhaps there could be 2 main sections. Constructing and Custom App Dev. App dev section: Getting Started -burning bootloader - link -Core Tools - link -MIOS Studio and Additional tools - link. Basic App Dev -PIC types/details + pros and cons - link -Using the mios programming platform - link -Coding in C/asm - link to links -mios functions - link -Common errors/warnings/messages, what they mean and how to fix - link Advanced App Dev -using module code - eg. IIC, sdcard etc. - link -Custom Linkers - link -?more thats way beyond my skill level :D Wikify Instructions -Link to 'how do I build a ...' template -etc -------------- yep.... big......

There's a few pages in the wiki that deal with using the different pic types that are outdated/incomplete I propose removing these pages and adding a new page that deals with the details of the 3 supported PICs and using them under the MIOS programming platform. Is there any docs about 'using' the new platform yet?

knarf: Just on the user app side of things. Getting relays to trigger from a button, or by midi input wouldn't be to difficult at all. It's getting them to work as part of a rig control patch that's the problem. It would require a massive change in the order data is stored on the master bankstick. Which then involves going through every line of code to punch the right locations in. Having had to this 3 times during the development of pedal board - I can assure you it's a lot of pain and suffering. :( With the FX looper concept, rig control can still trigger the relays via midi, and they can still be assigned to a button. The only real difference is how you setup pedal board to trigger relays in the looper. The end result will be the same.

Welcome Knarf! In short, no. Not without massive programming effort. The easiest solution would be to expand it with something like Flo's FX looper (work in progress) or a custom application. see this post: http://www.midibox.org/forum/index.php/topic,9770.msg98923.html#msg98923