Jump to content

Meeblip


bilderbuchi
 Share

Recommended Posts

Interesting... nice case idea.

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-quick-build-2.jpg

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.

MeeBlip-board-kit.jpg

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> :D

Hmm... I wonder if people would be interested in a MIDIbox equivalent hackable DIY synth... with a sammich style case... hmmm... :wink:

Link to comment
Share on other sites

Yeh it does seem rather odd... Maybe the MIDI socket pins are mirrored so you can mount them under the board *cough* :)

Hmm... I wonder if people would be interested in a MIDIbox equivalent hackable DIY synth... with a sammich style case... hmmm...

You mean a little synth where "hacking" actually means "modding" since it's planned for and encouraged? :whistle:

Link to comment
Share on other sites

you guys raise some interesting points. i figure you could always ask them and/or contribute your findings in the comments, i'd think that the guys over at CDM are quite open for feedback, and judging from their posts over the last year(s), alternatives are always welcome.

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.

Edited by bilderbuchi
Link to comment
Share on other sites

Hmm... I wonder if people would be interested in a MIDIbox equivalent hackable DIY synth... with a sammich style case... hmmm... :wink:

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.

Link to comment
Share on other sites

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.

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.

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).

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 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

Edited by polyfusion
Link to comment
Share on other sites

Hi James,

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.

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.

Link to comment
Share on other sites

welcome james. :)

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.

Edited by polyfusion
Link to comment
Share on other sites

If I would have the choice to use the enhanced flash memory either for comfort reasons (duplicated firmware), or for more synth features, I would always prefer the latter one :)

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.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fbootloader%2Fmain.asm

      MIOS8: documentation about the SysEx format: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fdoc%2Fmios%2Fmios_sysex_implementation.txt

      MIOS32 bootloader in C language: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fbootloader%2Fsrc%2F

      MIOS Studio - the part which handles the upload: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Ftools%2Fmios_studio%2Fsrc%2FUploadHandler.cpp

      Best Regards, Thorsten.

Link to comment
Share on other sites

If I would have the choice to use the enhanced flash memory either for comfort reasons (duplicated firmware), or for more synth features, I would always prefer the latter one :)

Agreed. The code is only 4K so far, so I have 28K of empty memory to play with for the near future.

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)

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.

Link to comment
Share on other sites

  • 1 year later...
  • 2 weeks later...
I was looking at getting the $39 option to 'mess' around with.

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:

Edited by polyfusion
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...