lis0r

Signed up as #5 on the wiki.

The static approach would be to declare oversized arrays, and only use as much as you need. This has the advantage that you never have to worry about allocation overheads, heap fragmentation, or running out of memory. An alternative approach is to couple this idea with a pool (e.g. static array and usage bitmap) of fixed memory blocks. As well as eliminating the danger of fragmentation, you can conceptually reset the pool on mode change, removing dangling pointers. A lot of these concepts are similar between embedded work and video games, so if you google for "memory allocation in games", you'll find some useful articles.

Those error messages are related to memory allocation (sbrk_r) and clean up on termination, so don't be entirely surprised if they show up again later, because it looks like a library mismatch. You can write object oriented code with dynamic memory usage in C, you know. Just pass a structure in as the first parameter, and use malloc/free. C++ is mostly just a load of cruft and baggage to hide doing the same thing. Given you've had worries about performance for this project, you should keep a close eye on the overheads C++ will be introducing into your code base. Profiling, metrics, and some good test code will save you a lot of headaches later on.

Will the SMT version require BA662s, or are you going to put something like this circuit on the board? http://wiki.openmusiclabs.com/wiki/BA662 Either way, awesome stuff :)

Disclaimer: my experience is mostly on MIPS. I'm sure TK already knows all this, too :) FreeRTOS is an embedded OS. These aren't OSes in the same sense as a desktop machine. If you think of it as a multitasking library, you'll be closer to the truth - it doesn't really handle interrupts, it has no real concept of DMA transfers. You don't need to take FreeRTOS out to regain control, because it doesn't really have it in the first place. You can put high performance control code in place, and leave FreeRTOS to deal with the low priority stuff.

A neat trick for generating good pseudorandom patterns is to use the cadences of speech. I automated this by taking the text of Alice In Wonderland, passed it through a text-to-speech engine to extract the phonemes and timing information, and then classified the results to get a beat pattern. The following web page contains preprocessed data, and grabs a random 16 beat chunk of the result - voiced on the top line, voiceless on the bottom: http://www.bismuth83.co.uk/~lisa/madhat.html

https://soundcloud.com/oh9/sorry Whilst being a long time hard trance lover, I'm a relative newb when it comes to making music. This is only my second piece :sweat: The bass, lead, pads and counter melody were all made on my MB-6582, though they've been processed a fair bit :)

As for motorisation - easy, take a page from the RepRap rule book. Spectraline: http://richrap.blogspot.co.uk/2013/08/3dr-reprap-delta-printer-part-2.html

No, I don't mean using touch sensors as touch sensors. I mean using them as the internal mechanism within the fader, triggered by a lump of metal attached to the knob carriage. If you want a concrete example, see the InnoFader. Should be easier than building an optical or magnetic fader from scratch.

Wouldn't a DIY capacitive slider be easiest? Pretty much a capacitive touch slider, similar to http://www.elektor.com/capacitive-touch-slider-sensor-module-ebm014 , with a metal block taking the place of the finger, attached to the bottom of the knob.

How many DFTs can a mutli-GHz, multicore ARM board manage? Surely that's the competition at this price point, not an STM32? It's also not clear how well optimised the DFT code under comparison was, or whether it leveraged NEON, etc.

It's not a heat sink - it's an extended surface! :tongue: Point being, the greater the surface area, the easier the heat can be transferred to the air.

I was thinking bigger! Ambika is stunted by it's open source zealotry and insistence on through-hole. Get an embedded multicore GHz MIPS/ARM/whatever board in there, use the infrastructure to control soft-oscillators, filters, and effects, and build a Virus killer! :D I've got a CI20 board I was going to turn into a synth - I just need to find some free time to write the DSP code. At the moment I'm having too much fun making music! I was going to hook a few knobs up and add a 7" touch screen, but something like this seems more suited! :)

All it needs now is a big screen, a high end microcontroller board, and some wavetable oscillators plumbed into the MB SID 3 platform ;)

xoxshop.de still seem to list the PT10? Possibly not local, but I had to order things globally to gather the needed parts.

Hi all, I've got my MB-6582 working enough to play with it a bit, while I add the finishing touches. I'm mystified by the feedback pots though. They seem to have little effect on the sound, other than making it quieter. They also seem to effect the sound all the time, even when "ext in" isn't switched on. Have I done something wrong? Thanks! Lisa

Indeed not, I did it by being too keen, staying up too late, and hooking 9V instead of the next pin down to CS by mistake.

Looks like it was the MIDI interfaces! I definitely toasted a line on one of the PICs though, so the PICkit 3 and spares will definitely come in handy. I now have 6 channels beeping via their SIDs :D Thanks for your help!

Sadly, the Behringer was even less successful - if it still doesn't work when I've got my MB6582 working, I'll add it to the wiki. I tried the novation from a Windows PC instead of my Mac, and that didn't work either. I guess I'll build a new power supply while I wait for an M-Audio Uno, a PICkit 3, and some fresh PICs to turn up. I figure that way I'll have all my bases covered!

Hi Tim, So I reflashed a core with the bootloader+mios image. When I hit query, I get the right response, then it continually blasts out: f0 00 00 7e 40 02 0f 00 f7 I then upload the test tone app, and it repeats: f0 00 00 7e 40 02 0f 00 f7 f0 00 00 7e 40 02 0f 6b f7 f0 00 00 7e 40 02 0f 00 f7 f0 00 00 7e 40 02 0f 40 f7 f0 00 00 7e 40 02 0f 45 f7 If I then power cycle, it seems to go back to randomly resetting. The same seems to happen with the other "bad" cores. The "good" core will both accept the test tone app upload, and produce the test tone from both SID sockets, when inserted into any PIC socket. It shows no sign of randomly resetting. This suggests to my limited experience that the board is OK, and I've managed to break the PICs :( I'm assuming this couldn't be an artefact of a dodgy MIDI interface? The Novation SL remote series seems to both be on the black and the white lists?! I'm going to reprogram all the PICs back to "clean", then I'll try programming them with my behringer fca1616 tomorrow.

Hi Tim, I'd just like to reassure you that I expect the chips were fine before I got my hands on them! Thanks very much for the advice, this gives me some great starting points to look at tonight. If you could send me the PICkit-ware binaries, I'd be very appreciative! Thanks! :) Lisa

Hi all :smile: I've built up my MB6582 base board, and all the voltages check out OK. All the PICs seemed to be working. I was able to connect to all four of the cores, and upload the test tone app. Core 3 works, however, cores 0-2 don't. I can query them, but an attempt to upload firmware bombs out 20-40% of the way through. They sporadically but rapidly spit out the following MIDI data: f0 00 00 7e 40 00 0e 0b 01 f7 f0 00 00 7e 40 00 01 f7 I'm assuming they're rebooting? I've tried swapping core chips, and the good core works in whichever slot it's in. The voltages to the PICs seem steady. I'm going to borrow a PICkit3 from work and see if I can reflash them back to "new", but I'm not hopeful. Have I just got bad PICs? :( Also, on one of the PICs, I'm pretty sure I accidentally wired 9v on U1_SID to pin 8 - is there any chance this hasn't damaged the PIC, or should I just order a new one now? Thanks!