lis0r

Presumably that'd be two U shaped switch plates per unit with 24 cherry shaped holes as well as any mounting holes. Are there any companies that specialise in making cherry switch plates, or would we have to engage the services of a general metal workers? They sound expensive!

Good diagram. If strength of the front plate is a serious worry, it seems like plate mounted key switches would be better than plain PCB ones? I know this heresy here, but if depth is getting to be an issue, how about a pure SMT all-in-one core & I/O board? Soldering an STM32F4 might be intimidating to a newbie, but it doesn't look as if it'd be hard.

Sure, more options are great. It'd be nice if it wasn't made incompatible, though, especially if it doesn't result in a significant cost difference. It'd be nice if the boards enabled users to express their design preferences, rather than mandated a cheap end result.

The images I saw seemed to have space at the left and right edges? Could the bolts not go there, perhaps with reinforcing struts behind to prevent flexing?

I must admit to being slightly confused - is this because the keys get in the way of bolting to the front panel? Or are they just deeper to the point of causing issues?

The heidenreich case was never required. Being compatible with it surely only requires that the boards don't end up too big to mount behind the given panel space, which doesn't seem like too onerous a requirement?

Also, for keycaps, is there a friendly laser engraver owner who could experiment with marking? I also wondered about paint black and then using the laser to remove it so the light could shine through the words. http://keycapdiy.blogspot.co.uk describes DIY dye sublimation, but it's kinda difficult. Perhaps a group but could be arranged with them, though, if it's beyond us?

Talk to the guys behind https://www.modelfkeyboards.com , and get some seriously overspecced keys? More seriously, will these boards fit the custom aluminium cases? I've had one waiting for me to gather the other components for a seq.

I'm afraid I can't really help much more - I use the board as a reference platform for developing our in-house RTOS and hypervisor products. We have been considering getting some boards made up with CellularRAM attached to the external RAM interface. These are basically DRAM+controller, packaged to behave like SRAM.

Nope, we've always used the 144 pin parts, so we've never had a problem with the amount of I/O.

I use these at work for testing, they're nice enough chips. I've been meaning to use some for home projects for a while now, but haven't gotten around to it yet. Lisa

I'm slightly disappointed that the FM mode seems to have been ditched. It was always going to be pretty basic 2-op stuff, but some of the demos of the old SwinSID sounded pretty good!

It'd be a useful addition for midibox synths to have a trigger input available, so the display can be synced with the fundamental, rather than at an arbitrary zero crossing. The extreme stability and predictability of the miniscope on the Korg Minilogue makes it so much more useful than some of the other 'scopes I've played with.

I'd try properly programming the PIC18 before deciding which core you're going to use. I submitted a patch for MBSID, and I'm a very experienced, multi-platform, assembly coder for a living. Whilst it wasn't hard, issues like there being no conventional memory, segmentation, and the restricted instruction set made it a pretty unpleasant experience. Certainly, the MBSID software was incredibly low on spare "memory", which made it much more difficult to make any modifications. If the same is true for MBFM, then you may find your modification options very limited.

Access are renowned for being uncooperative, aren't they? Hence the lack of service manual and schematics online? They'd much rather send you to their pet technician The audio input on my Virus C is dodgy, but when I went looking, I could find almost nothing about what might be wrong. A far cry from my great experiences repairing my Supernova 2!

Maybe install a Linux VM, and try building inside of that? MSYS, cygwin, etc. are always a painful experience.

Hi Pierre, Is there any news on this bulk order? Thanks!

Having to push data out every few microseconds sounds realtime. You should probably be doing that in a timer interrupt. The non-realtime part of the code should be converting the data from the on-disk format to a representation that makes real time processing easier. That's assuming you can't figure out a way of getting a DMA engine to do the job for you. From the description of your current scheme, it will be exceptionally fragile. At the very least, you still shouldn't be polling - you should be able to work out when you'll need more data. Schedule a timer to initiate the reads, don't waste CPU time polling.

Read the appropriate FAT entries at file open, translate from file offset to cluster numbers when filling out the descriptor, and voila: queued, streaming, asynchronous file I/O, without desktop-levels of spurious tasks. Think embedded! You shouldn't have *any* "mid-priority task"s that "comes around every so often and checks" *anything* - polling is ugly and inefficient.

I still think it would make more sense to utilise an existing blocking synchronisation primitive than try to hack around the scheduler, especially if the intent is to be OS agnostic. Personally, I'd use queued I/O. You'd have a shared request queue, and a receive queue per task. The process would be like follows: In the requesting task: 1) Build a transfer descriptor. This describes the data to read, where to write it, and specifies a receive queue to be notified. 2) Queue the descriptor on the request queue. 3) If the queue isn't running, in a critical section configure and start the request on head of the queue. 4) Perform a blocking read on the receive queue. In the DMA ISR: 1) Pop the head of the request queue, and write a notice of completion to the receive queue it describes. This should cause the task to wake up. 2) Check if there is another request. 3) If so, initiate it and return. 4) If not, mark the queue as not running and return. This gives you efficient blocking I/O without the overhead of another task. It's also worth checking if someone has already done the work of wrapping up queued I/O for you - it's certainly a feature in my pet RTOS.

http://www.freertos.org/FreeRTOS_Support_Forum_Archive/June_2007/freertos_portYIELD_FROM_ISR_1752080.html explains how you need to approach this. I think you should use the xTaskNotify() family of functions, instead - the kernel has already implemented blocking, there's no point reinventing the wheel.

Hopefully those of us outside the eurozone can still use paypal! :)

SWIFT/IBAN is prohibitively expensive from my UK account :(

If I have to take the hit of extra cost, I will - the assorted extra percentages hit UK punters on the list a bit harder, though. I'm personally in no huge rush, though, so if the bulk order is left open longer to allow some other people the opportunity to join, that's not a problem either. I guessing from interest levels, there's unlikely to be another bulk order for a while?

Given it's unidirectional, why not go the whole hog, and go optical? Mini toslink (the ones that look like 3.5mm jacks) would be kinda cool.