meeblip / meeblip-triode Goto Github PK

When I set the midi channel to 8, the triode reverts to channel 0 / omni mode on power up.

The initialize code checks for midi channel < 5 but we can now pick values from 1-8 as valid midi channels?

initialize.inc line 223

cpi     r16, 5                  
brlo    LOAD_MIDI_CHANNEL       ; If stored MIDI Channel is not Channel 1-4, set synth into MIDI OMNI mode.
ldi     r16, 0

Seems that you should check for values less than 16 instead, and worry about how many channel the synth supports somewhere else.

In the future, you could check for a change in the state of a switch to toggle between midi 1-8 and 9-16 and support setting the synth to any channel. and not just the lower 8 channels.

In wavetable mode, the GLIDE knob selects wavetables. It should respond to MIDI CC (as should the WAVEFORM switch to allow switching between wavetable banks).

Since the MeeBlip is Open Hardware / Open Source, would you mind adding a Bill Of Materials to the repository? Also I'm guessing you don't have a bootstrap and program the ATMEGA chip directly?

I might play with an alternate build at some point, but I'll probably do it on a separate chip, and keep yours for the "official" build.

Great little bass synth BTW, it sounds really dirty but that's not a bad thing.

There is an issue reported by a user on Reddit that the Meeblip Triode has issues receiving MIDI note on messages when receiving a number of presumably unknown MIDI messages, probably either MIDI Song Position Pointer or MTC message.

Looking at mini_in.inc, as of commit c66a3ed, there is code between lines 23 and 29 which immediately removes the Triode from the interrupt caused by a MIDI message sent should it be a byte between F0 and FF. And, indeed, when my Triode gets a MIDI Beat Clock message from my Korg ER-1 along with note-on commands, the Triode is able to play the notes without problem, since MIDI Beat Clock only consists of the bytes F8, FA, FB, and FC.

However, the Triode stops being able to respond to MIDI messages when getting more complicated unknown MIDI messages. Looking at mini_in.inc, the issue appears to be that, when MIDIPHASE (the byte of a MIDI message we are looking at) is 0, and an unknown byte is received, instead of immediately exiting from the MIDI interrupt, mini_in.inc compares the incoming byte and MIDIPHASE to a number of possible values before finally exiting the interrupt.

To resolve this, I propose adding two instructions right after the INTRX_DATA jump point, on line 73 of the current version of midi_in.inc, like this:

INTRX_DATA:
 lds r17, MIDIPHASE ; This is already here on line 73
 cpi r17, 0 ; On the old 6502, this isn't needed 
 breq INTRX_ACPT_X ; Which will jump us to INTRX_EXIT
 cpi r17, 0x80 ; This is in the current code; go on as the current code does

Thoughts? This fix should make the Triode more useful when slaved to devices which send complex MIDI data when sending out a clock signal over MIDI.

Edit: Looking at the code again, INTRX_ACPT_X is close enough to this that we can call that with BREQ

Hi, I have a triode and have only recently been playing with wavetable mode. I've also gotten a new sequencer recently and in programming in the various CCs for the meeblip, I noticed that the three-way switch only does positions one and three via MIDI, right at value 64, as you'd expect from a two-way switch. The hardware works fine. I think that I confirmed that you can't get PWM via MIDI either.

Also a feature request, albeit one that might not be possible: I'd love to be able to trigger wavetable mode via CC as well, as it'd go a long way towards being able to replicate patch memory in the sequencer.

Lastly a hardware question: is modding the triode to be actually mono as simple as snipping the ring legs on the socket, or will that not work?

Same as #4 it would be great if the Midi CC control of the sustain part of the envelope was the full range rather than just a switch.

I'm getting a lot of stuck notes and missed midi events from my MeeBlip when driving it from the Squarp Pyramid. It would be great to have the midi button stop all open notes when pressed ( or whatever scheme would allow me to have a quick "panic button" to use.

Alternativelly, supporting the "AllNotesOff" midi message would also be great.

I'm actually tempted to replace the pot for the detune parameters for one that has a hardware center detent. But for everyone else, having a virtual center implemented in software, where the values are shifted so it's easier to keep the oscillators in tune should you want too.

Looking at the code, (not an Assembly programmer, so it reads, very very slowly) it seems possible to support control of the sub-oscillator level from Midi CC (I guess a mult rather than a if somewhere?) . I would change the way the CC#64 works by using the full range 0-127 for volume, instead of on/off at >=64. You can still have full bypass of the sub calculation at level = 0

Also is the sub-oscillator 1 or 2 octaves down? This is orthogonal from the Midi CC question, but since your switches have 2 states, you could actually have the sub function as Off/-1/-2