Meeblip Open Source hardware synth
#1
Posted 10 November 2010 - 15:51
Meeblip, The Open Source, Hackable Digital Hardware Synth
http://createdigital...hardware-synth/
#3
Posted 11 November 2010 - 03:14
What I don't understand is why the PCB in the "Quick Build" kit is a different PCB to the "Full Board Kit" kit.
MeeBlip Quick Build Kit
A MeeBlip anyone can play – with everything you need already in the box. No soldering required!

MeeBlip Full Board Kit
No case or overlays – suitable for those wanting to make their own enclosure. You solder the board yourself; some basic soldering experience recommended.

Note the extra "rear ports" PCB in the Quick Build kit. I think the MIDI and USB sockets are supposed to go on that PCB and not the bigger one, and then they stack via a male/female header.
So the Full Board kit doesn't have this rear ports PCB... therefore the MIDI socket will have to go on the same PCB, DIN sockets are max. 20mm high, so... how are you supposed to make your own case with a 20mm MIDI socket while the switches and pots are all short? You need something like a 7mm gap between PCB and top panel, and even then, the switch actuators would only poke out 2mm for a 3mm top panel. 7mm < 20mm. Hmm...
I suppose you could DIY your own rear ports PCB or use panel mount sockets... still, it's a shame that the kit aimed at hackers wanting to "make their own enclosure" are screwed over by the stoopid big fat MIDI socket on what is essentially the control surface PCB.
</rant>
Hmm... I wonder if people would be interested in a MIDIbox equivalent hackable DIY synth... with a sammich style case... hmmm...
Buy Wilba a Beer Disclaimer: buying Wilba a beer gets you absolutely nothing in return likesuchas sammichSID kit order queue jumping, purchase of SIDs and MIDIbox troubleshooting assistance.
#4
Posted 11 November 2010 - 08:27
Quote
You mean a little synth where "hacking" actually means "modding" since it's planned for and encouraged?
Buy nILS a Beer Disclaimer: buying nILS a beer gets you absolutely nothing in return likesuchas real-time chat support, gm5x5x5 pcbs, MIDIbox troubleshooting assistance or a less grumpy german.
#5
Posted 11 November 2010 - 09:55
one thing i don't get is the decision to require a chip flasher to reprogram the device - the midibox way is soo easy/comfortable. I think this will stymie software development quite a bit.
This post has been edited by bilderbuchi: 11 November 2010 - 09:59
#6
Posted 14 November 2010 - 15:35
Wilba, on 11 November 2010 - 03:14, said:
Note that sammichSID is already a fully hackable DIY synth, it's open source, it's easy to build.
So, the idea itself isn't really new, although some websites (which mostly take Arduino based designs as basis) promote this as something new and special...
We go this way since more than 10 years. ;)
A digital STM32 based synth in a sammichBox would be nice of course!
Best Regards, Thorsten.
Buy TK a Beer Disclaimer: buying TK a beer gets you absolutely nothing in return likesuchas firmware enhancements, technical advices and MIDIbox troubleshooting assistance.
#7
Posted 15 November 2010 - 00:28
I was thinking something more like the "I made noise with my core32" synth.
Buy Wilba a Beer Disclaimer: buying Wilba a beer gets you absolutely nothing in return likesuchas sammichSID kit order queue jumping, purchase of SIDs and MIDIbox troubleshooting assistance.
#8
Posted 15 November 2010 - 21:43
Wilba, on 15 November 2010 - 00:28, said:
I had a look at the Meeblip this afternoon and had the same thought. Would put my money on the STM32 if i had to make a choice.
#9
Posted 23 November 2010 - 00:54
Wilba, on 11 November 2010 - 03:14, said:
What I don't understand is why the PCB in the "Quick Build" kit is a different PCB to the "Full Board Kit" kit.
Thanks for spotting MeeBlip. The Quick Build board has cutouts for posts inside the case, that's all.
Quote
Yes. More or less correct. If you're going to install that board in a case, the connectors are mounted on the smaller daughter board on the bottom of the case and connected to the main board using a jumper cable. We had to do it that way because the rear panel of the case isn't at right angles to the top panel (which would have allowed us to mount the connectors on the bottom of the main board).
Quote
You can do it two different ways.
1. Mount the switches and pots on the circuit board, and connect external audio, MIDI and power connetors to the rear panel of your case.
or
2. Mount switches and pots directly to the front panel of your case. There are header/solder points to allow you to wire external switches and pots. If you do this, you will probably mount the MIDI, audio and power jacks on the board at the bottom rear of your case.
As far as using MIDI SysEx to update the firmware instead of requiring an AVR programmer: We're considering releasing a bootloader. The problem is that the MIDI interrupt has to be disabled when programming the AVR's flash memory, and there isn't enough RAM on the chip to stage the firmware into RAM before writing to flash. That means you have to bring it in slowly, in 1K segments.
Cheers, James
This post has been edited by polyfusion: 23 November 2010 - 01:00
#10
Posted 23 November 2010 - 01:19
polyfusion, on 23 November 2010 - 00:54, said:
If you are interested I could give you the details how to interact with MIOS Studio
It can transfer any .hex file, offers checksum protection and retry mechanisms; it isn't restricted to PIC and STM32.
In any case, I strongly recommend you to reduce the block size to < 1024 bytes because some dedicated MIDI drivers under Windows (e.g. M$ legacy USB-MIDI under WinME) have such restrictions for SysEx streams.
Best Regards, Thorsten.
Buy TK a Beer Disclaimer: buying TK a beer gets you absolutely nothing in return likesuchas firmware enhancements, technical advices and MIDIbox troubleshooting assistance.
#11
Posted 23 November 2010 - 03:33
TK., on 23 November 2010 - 01:19, said:
It can transfer any .hex file, offers checksum protection and retry mechanisms; it isn't restricted to PIC and STM32.
Excellent. Yes, that sounds like a good solution. No point in reinventing the wheel.
#12
Posted 23 November 2010 - 10:32
TK, how to go about the missing midi out on the meeblip with respect to checksums and retries?
This post has been edited by bilderbuchi: 23 November 2010 - 10:32
#13
Posted 23 November 2010 - 17:16
bilderbuchi, on 23 November 2010 - 10:32, said:
TK, how to go about the missing midi out on the meeblip with respect to checksums and retries?
Easy answer: Version 2 of MeeBlip needs MIDI out.
I've got enough empty flash memory that we can store a duplicate copy of the firmware. So, if a block fails a checksum the synth could terminate the firmware update, flash an error code and restore the previous firmware.
This post has been edited by polyfusion: 23 November 2010 - 17:16
#14
Posted 24 November 2010 - 00:09
Basically the MIOS8 bootloader works the following way (please note that "MIOS" doesn't mean that an adaption of the MIOS operating system is required):
- 1) whenever the chip is powered up or reset, the so called "1st level bootloader" sends an upload request (a specific SysEx string)
- 2) the bootloader stays active for two seconds, and if it doesn't receive a response from MIOS Studio, it checks for a "magic word" at a special memory location. If it exists, MIOS, resp. the actual firmware will be started. Otherwise it restarts at 1)
- 3) a received code/data block will be programmed into flash/EEPROM, thereafter the bootloader restarts at 2)
- 4) MIOS itself provides a "2nd level bootloader" with enhanced features.
This approach has following advantages:
- no special pin required to select bootloader mode. This means that users can update a firmware w/o opening the device, resp. adding a special switch to the case
- due to 2) and 3) code can even be uploaded without the bidirectional protocol.
E.g. firmware could be embedded into a .mid file, or provided as a .syx file (some SysEx tools allow to insert delays between SysEx blocks)
This means that code could even be uploaded if no MIDI Out is connected (but debugging capabilities are limited - users don't get diagnose messages if code upload was ok and complete). - due to 4) it's possible to upload new code during runtime w/o touching the device
- due to 1) following mechanism is provided: to upload a new firmware, press "START" button in MIOS Studio and repower or reset the device -> upload will start automatically. This is a fallback solution for the case that the application hangs up (e.g. caused by a programming error during development of new code)
- due to 4) it's possible to keep the size of the 1st level bootloader limited to less than 1k
The 1st level bootloader only supports the programming of internal flash and internal EEPROM.
The 2nd level bootloader (part of MIOS) allows to program external EEPROMs in addition.
With MIOS32 I modified the bootloader approach a bit - since much more memory is available (512k flash), I reserved 16k for the bootloader so that some "dreams came true" (also because it wasn't required to consider incompatibility issues ;)
- 1) native USB MIDI support makes code uploads even faster than via JTAG! UART based MIDI still provided
- 2) bootloader mode active for 2 seconds after power-up/reset like before, a LED flashes to notify that the chip is running - thats an important debugging help for DIY people who want to check if the chip is up&running at all.
- 3) once code upload has started, bootloader mode won't be exit anymore before a special command has been received (solves the race condition of MIOS8 bootloader)
- 4) added a special "bootloader hold" pin which lets bootloader activated as long as a certain jumper is connected on the board. It ensures that code can be uploaded via USB-MIDI even if the application crashes (because Windows/MacOS needs some time to detect the device)
- 5) 2nd level bootloader has been removed. Instead a special SysEx command has been added to enter the initial bootloader during runtime (so that the complete firmware can be updated - no separation between MIOS and application anymore)
- 6) MIOS and the bootloader allow to query parameters, e.g. Flash and RAM size, but also chip derivative, the "Board ID", application version, etc. - they could be considered later to select the right firmware for the given infrastructure, or just to abort the transfer if the .hex file doesn't fit into flash, or to warn the user if the usage on a certain derivative or "board" is risky.
Both solutions are failsafe: if the application crashes (e.g. due to a programming error or corrupted firmware upload), the bootloader will still be available so that code can be uploaded again.
More safety can be added by protecting the flash section where the bootloader is located, so that the appr. code can even not be overwritten if the application should ever branch to a code fragment which initiates a flash erase or programming sequence.
For the next steps I would recommend you to decide if you prefer the MIOS8 solution (less code size) or MIOS32 solution (more flexibility).
You could also define an own approach, MIOS Studio is flexible enough to handle multiple solutions (I would add this on request)
Sources (for reference - more details on request):
MIOS8 bootloader in assembly language: http://svnmios.midib...ader%2Fmain.asm
MIOS8: documentation about the SysEx format: http://svnmios.midib...lementation.txt
MIOS32 bootloader in C language: http://svnmios.midib...loader%2Fsrc%2F
MIOS Studio - the part which handles the upload: http://svnmios.midib...loadHandler.cpp
Best Regards, Thorsten.
Buy TK a Beer Disclaimer: buying TK a beer gets you absolutely nothing in return likesuchas firmware enhancements, technical advices and MIDIbox troubleshooting assistance.
#15
Posted 25 November 2010 - 16:29
TK., on 24 November 2010 - 00:09, said:
Agreed. The code is only 4K so far, so I have 28K of empty memory to play with for the near future.
Quote
You could also define an own approach, MIOS Studio is flexible enough to handle multiple solutions (I would add this on request)
I am leaning toward implementing a version of the MIOS8 bootloader, but I need to read the docs first. I really like not needing an extra pin to initiate the transfer (critical in this case, because there are no extra pins).
Thanks for the assistance - I think this will come together nicely.
#17
Posted 26 November 2011 - 01:38
I was looking at getting the $39 option to 'mess' around with.
http://meeblip.noise...micro-large.jpg
cheers
Paul
#18
Posted 09 December 2011 - 23:18
taximan, on 26 November 2011 - 01:38, said:
I'm happy to offer free shipping to any MIDIbox forum members who want to try the meeblip micro. It uses the same sound generation engine as the Meeblip SE, which includes dual envelopes, anti-aliased waveforms, PWM, variable pulse wave, FM, noise and full MIDI parameter control.
Back in the pre-historic early 2000s, Thorsten's work was an inspiration that encouraged me to eventually muck around with DIY kits.
Just visit meeblip.noisepages.com/get-one/ and use the discount code EUROMICRO for free shipping to the EU, or USMICRO for free shipping to the USA.
Oh, and here's a video showing the new iPad version of the Lemur controlling a V1 Meeblip: http://youtu.be/Grpn0WiqtRU
And an all-Meeblip track that shows a broader range of what it can do: Listen on Soundcloud.com
This post has been edited by polyfusion: 09 December 2011 - 23:22
#19
Posted 10 December 2011 - 01:52
Yaaayyyyy just ordered it........should go nice with all the other stuff I am accumulating...I might even make some music one day...lol.
cheers
Paul



Help



















