stryd_one

I agree, it would be good to have a somewhat louder warning... What do you think TK?

It hides it, sorta, but it's still there, slowing things down a little. Kinda depends on the application, but for 8bit parralel communications, it's naturally best to use an 8bit port :) That's right. You can see examples of it in the SVN modules/ directory. For example, we could provide something like void MATRIX_SetXPoint(Unsigned char row, unsigned char column); In all of the drivers for crosspoint switches, so that the app only has to make this function call, and whichever driver is included (easily configured at the makefile) takes care of the rest of the concerns with flipping the switch. This is a simplified example but I hope it gives you the idea. The only trick with that, is making sure the pins are handled correctly so as not to mess with the LCD. The LCD is not interrupt driven, so the two devices are not accessed simultaneously, so it's mostly about leaving the pins in a safe state when you're done interacting with the chip. By this I meant, I'd like to see your driver as a mios module like above, so various apps can make use of it :)

Nah it's just this thread, some draft layouts, and a bunch of chat logs at the moment... there'll be wiki doco once there's a bit more to tell, and it'll go into 'user projects' land.

Each part of this will be made public within about 10 seconds of it being tested and proven working, by the appropriate developer posting and celebrating loudly and doing the "it's working" dance and such. Once it's ready to be built and documented and all that kinda stuff, there'll be a bulk order for parts and pcbs. What's wrong with the MT88? it's probably very well suited to guitar patching, and significantly less expensive, and there are two projects to base your work on already...If you're keen to help develop, that would be helpful, or if you're a PCB layout whiz in eagle or kicad, shout out...

You can do subfunctions in other ways too, but I don't blame you for your software being heavy: like you said, it's the yamaha designers I couldn't figure out... I was going to suggest some optimisations but once i read the code I could see that you had little other choice (not knowing what the physical layout was) That said, if you made your matrix 8x6 to match the board, that would be a lot cleaner, and allow for smaller code that could be more easily included in other projects. All you have to do, is wire it the other way, and you could use the row/column variables to quickly calculate the note number, and leave two columns (now rows) of switches unused (perhaps they could be used for other functions later) But if it works for your purpose and the idea is not portability - why bother :)

Hehhehe... Let me guess, the skeleton is symbolic of the death of your much loved liberty?

A couple things: PM'ing stryd is not an alternative to waiting for a response from the forum ;) What are you trying to upload/what for? This post is in the wrong forum I think, but I don't know where to move it.

1) 64E now supports analog inputs (pots/faders) too, but I gather that the 64 has more complete support for them. 64 doesn't support encoders at all, so if you want to use them, you're making a 64E 2) Practical applications are up to your imagination ;) others) See nILS

I'm glad, cause that would be a short circuit! (Vd is +5V in this case, see the wiki, search for Vdd) If you still have the DINs connected to the wrong pin, that's why they don't work. Don't sweat what's printed on the silkscreen of the PCB, get out the schematics and check.

Look closer at seek's post... apparently -you- are running the group buy now ;)

Update from the chatroom: This all came down to wiring problems. We tracked them down and fixed them up, and the box became responsive, and then foona uploaded a change using serge's editor.... Which killed the bootloader on the PIC: There's a note on the ucapps page that says that serge's is not compatible with the PIC18F apps. Foona is now arranging parts for a JDM or burner......D'oh!!

@dj: 13 euro ouch! That's a bit steep. Sure mate we can use you for a test subject too :D @lyle: I'm still keen on keeping this project in C so it's easier for others to modify later on, so I don't think I could lift your code... but it would be good to make sure we maintain some form of compatibility between the apps if we can, so maybe they can be mashed up later if it's possible. That said, I'd love to get my greasy mitts on your code, thankyou! ;) FWIW, the drivers will all be ASM or C app compatible (just the app itself would be in C) so they should be useful to you too :)

j5a and b, are the same as j5, so you need only ground one or the other. You can do it however seems best to you really (sorry I always disable mine heh)

Try uploading the app (MB64 not MIOS) again, but that's very strange... And come to the chatroom ;)

Rad :) Don't sweat it man, you're not the first to cable incorrectly, and you won't be the last. Good luck!

The fatar keyboard would make way smaller code, it'd probably be better to take a different approach. julien has had to include that big switch statement because his keyboard skips a bunch of keys here and there (why? it's really weird!). The fatar keys are all in order, so it'll just need one function for sending all the note values, and an if statement to react to the function key for setting the octave.

That's an excellent description dude, that makes it a bit easier.... alas it's a weird problem. The "only pot 6 works" thing is rather interesting. I'd be taking a really close look at J6. In fact if you can wire it back to front (ABC -> CBA, or just rearrange two pins like ACB), it'd be interesting to see what happens. But those pins select which of the 8 pots on each 4051 are being sampled, so it sounds like they're held at CBA = 110 somehow. Time to get out a magnifier and a multimeter... Edit: check the whole trace for shorts, all the way from the PIC to the 4051...

As you can see below, I've got my hands on them. A small number of people have volunteered to help develop this and the chips will be going out to those people, and then after that we'll get a bulk order going for people to build stuff up. At the moment we're finalising the PCB layouts, and should have them in hand and ready to solder within a month or two. That includes the common layouts used for all the other chips, like buffers and PSU and such. I'm glad to see that interest is strong in the MT88* chips, because at that point it would be really good to have someone to help test on that platform too. If you can get a PCB and the chip in-hand, then we can have extra pcbs made up for you for the buffers/psu/etc, and I can help to make a driver for you if you need it. Same goes for the 8113, if anyone's feeling all audiophile ;) As far as software, it's fairly scare at the moment, about the only thing fit to show is the mod_skel module and application skeleton which I have been using as a framework (already on SVN). I've been using some other stuff to write driver modules, so I can 'learn the ropes' on something where I actually have the hardware. I'm just about done with those, so by the time the PCBs arrive we will have a AD75019 driver ready to roll into it, and get to work on the bank switching and other CS stuff. That's the sitrep...

Yeh, blame wilba.

It has a few differences, have a look at the manual, there's a section on compliance. Well yes and no... J5 is spread across two IO ports (A and E) so it's not the greatest for that. As soon as I get a fix from the SDCC guys for inline functions, I'll be releasing the driver, schematic and PCB layout for an extension that shares the LCD like I mentioned, you could maybe use that as a reference... should be a few days away. You got the right thread. If you're thinking about writing a mios driver then we can make that app compatible with the driver. It'd be great to be able to use it in both hardware designs :)

If you can write code and never screw up then you might like to try walking on water ;) Ahh I see what you mean about the change now, and it's not sending invalid midi, i just misread the log... I'm sure mios studio lets you paste the text no? I'm still not really clear on the problem... Does it happen to all pots or just the one? Does it always increase the channels, or does it decrease sometimes too? does the change in channel have any relationship to the way you turn the knob? Apart from uploading fresh MIOS and application, what other changes would you make, to get it configured for your hardware?

Take a look at the module skeleton on SVN, and the application development section on the wiki for more answers. If you take a look at the asm files in the output you can see how the ASM for that looks, should give you a hint... But yeh, the C interface will work fine. You could use the LCD's RW line for the strobe and the RS line for data pins, and use extra pins for CS lines, for best flexibility. There's a few things in that code that won't work in SDCC I might as well mention now: there's no bool type, and you can't declare counter vars in the for statement. That said, I don't see what's so bad about using serial control? should be only 1-2 milliseconds of latency at worst, between pressing the button and flipping the switch... ...and, this is exactly what we're doing in that other thread that you said was too complex hehehe... why not join the party? :)

That midi monitor is not much chop.... the way it inserts an F0 like that is really annoying, as is the lack of ability to select the text! Glad it's working now though... really strange that it works with miosstudio and not serge's though.... Something weird is going on.... Oh wait you add-edited (man that's a bad habit) What change was that? You've got it sending invalid midi messages, that's bad. Makes me wonder what else you broke ;) Anyway, that is an aside: Fix ONE thing at a time.