Messages

Ah I think this may be down to the filter algorithm.  Are you using the more extreme dB filters - the 100dB parametric and the high and low shelves?  The maths can go a bit wrong if pushed too far with these ones.  Not yet found a solution, I think it may be to do with the 8-bit calculations of the floating point algorithms.  I won't go into any more detail before confirming we're talking about the same thing.  Next time it happens, goto filter type and switch up and down a value and let me know if sound comes back. thanks!

Oops - this is a bit embarrassing, the wrong version was on the website!  V1.1 was quickly replaced by 1.2 when I realised that I hadn't put any programming in for ext MIDI clock!  I've updated the downloads page now.  http://soulsbysynths.com/wp-content/uploads/2016/04/StringsV1-2.hex
I gave it a quick check too and it's def syncing OK.
Paul

Great thanks.  Should be able to suss it out from that info.  I'll upload a new version to the website once I've sorted it.

I'll take a look at this over the weekend.  I've just had a quick look at the code and all the MIDI clk stuff seems to be in there and I feel sure I did test it.  I'll let you know what I find out when I test it.
Can I check - is it responding to tempo at all?  Ie the tempo is correct, but the phase of the cycler/phaser/LFO isn't in sync with the start of the bar?  Or is it responding to nothing (tempo or phase)?
The only essential thing to enable ext clk with all software versions is that the Atmegatron receives a MIDI clk start.  That should happen when you hit start on the Electribe.  If it works in normal Atmegatron software, then that message is being received OK.
Paul

Hi,
Had a chance to check the code! 
1)  Goto Min.cpp, then
void Min::engineValueChanged(unsigned char func, unsigned char val, bool opt)
This shows the code for setting the LED when the func is changed
The code for showing the value via flashes is just below in:
void Min::refreshValueLed()
You'll want to leave this blank, so it doesn't overwrite your new code in engineValueChanged

2)
The quickest way is at the bottom of Min.cpp in:
void Min::hardwareMidiReceived(unsigned char data)

However this code doesn't know what the message type is, it'll just allow a generic flash for any message received.  If you want to do different flashes for different messages you'll need to go to:
MinEngineBase.h
and add a callback called something like:
virtual void engineMidiReceive(unsigned char status, unsigned char data1, unsigned char data2) = 0;
Then add the relevant calls to it that you want in MinEngine.cpp (e.g. in void MinEngine::midiNoteOnReceived(unsigned char note, unsigned char velocity))
Then add it to bottom of Min.h
Then add it to Min.cpp with the required code for setting the LEDs.
A bit more complex, but you can find examples all over the Atmegatron libraries for using these base classes for callbacks.  Just copy an example where you find a "base_->" in the code.

hope this helps!

Hi Simon,
Yes all of this is possible and not too tricky with a bit of C/C++ knowledge. I'll be able to look at this properly tomorrow to help - I wanna make sure I give you the right info when I've got the code in front of me!  Best that I don't try and do it from memory!
Paul

https://www.thonk.co.uk/ will be launching them in a matter of weeks now.  I'm also getting more stock in maybe a month or so from now.

Will def have hacked Arduino and cases available too.

Yup they're identical.  The black end of the FTDI cable aligns with the GND pin and the green aligns with the RTS pin (called DTR on the Sparkfun board).  Not sure what type of port the micro-granny has, so you may need to make a bodge lead, but as long as you do a pin to pin connection from the FTDI cable to the micro granny, it'll work.

Great news! 

Can I check a couple of things:

• Serial number
  
• Did you buy your own FTDI cable or did it come with it
• Can you confirm that you've set the Atmegatron up as per this picture: http://forums.soulsbysynths.com/index.php?topic=56.msg117#msg117

thanks
Paul

Yeah I know what you mean.  Lots of sounds all on same beat + high pitch = freezes up! 
I wrote that quite a long time ago now.  I'm getting much better at putting safety measures in to prevent it seizing up.  Atmegadrum is definitely at the top of my list to bring up to date.  Hopefully will get on to that in a month or so, once the Oscitron is out.

Hi,

Answers are:
1) Afraid drum is currently locked to channel 1.  When I convert the software to use the new libraries, MIDI channel change will be possible
2) Yeah you'll either need to turn off sync, or clear the pattern in memory.  It will always start when it receives a clk start message
3)  At the moment there's nothing - I wanted every byte possible for drum sample memory, so stripped everything out.  I may see if I can add some again when I convert to the new libraries, which uses more efficient code.

Having issues with assembling your miniAtmegatron case?  There's now 2 help resources:
1) This excellent tutorial thanks to Jesse at Bent-Tronics https://youtu.be/byy6cBudFX8
2) Some tips on getting the case to fit http://soulsbysynths.com/wp-content/uploads/2015/08/miniAtmegatron-Case-Assembly-Tips.pdf

Yes that's correct - eeps and hexs with the easy uploader. Mems with the librarian.

Ah yes - this is a little different to all the other software versions.  This is because there are so many parameters, some of them are chosen by selecting red/yellow mode (ie orange / white). 
So turn function knob to Porta/Patch
Push knob so it's red (yellow = portamento)
turn Value knob to select patch number
short press value knob = load patch
long press value knob = save patch
Note:  the value knob can't be used to test a note when the Porta/Patch function is set to patch (red).