yeah, I used the mouser one supplied - just watch out for items marked as 'backorder' , it can be easy to miss, and if you backorder there is no guarantee they will deliver (as I found out to my cost on the 8mm headers)
so the 6.7mm headers arrived, and they were much not longer than the standard, so im waiting on the 8mm to turn up from UK , should be next week.
another thought on the 'make salty' idea.
one thing I would really like is for the 'make system' to automatically add a
BELA is true in all cases, as SALT and PEPPER are derivatives... but help my cross platform code.
(thoughts on how this is best achieved? if I was to do it and make a PR?)
why you might ask?
1) why not add this to the settings ? (thru bela ide)
because I share the project across multiple bela platforms, and that projects compiles and runs for all 3, so they can share the settings file (which is all in the GitHub project)
2) why do you need it?
because some behaviour changes are required due to 0..1 representing either 10v or 5v
also some things are different, e.g. what digital outputs are used for
3) why salt/pepper? can they be similar
yes, with certain functional changes
whats nice about salt/pepper is they are a 'fixed UI' , we know what is (generally) available to the user so patches can be generic... and also I want my patches to run on both salt/pepper without editing.
(I currently do between salt and plain bela, but I then have to assume certain hardware connections on bela)
4) is PEPPER enough?
good question, we might need an extra definition e.g. PEPPER_ANALOG, PEPPER_DIGITAL
which can tell a patch if the pepper is setup with the last 4 inputs as digital or analog
5) what about it PEPPER has no LEDs rather dip switches
sure could be another #define, but honestly I don't see many doing this, so its not the main use case,
also we could get into cases where there are different custom options, that are really kinda impossible to support at patch level without code changes - so I think its an 'edge case'
generally, what id like to do is to get salt/pepper into a situation where we can more easily share patches (e.g. on patchstorage) … and also given pepper is likely to sell better(? due to price), it makes sense to make it easier to make the patches 'compatible'
also there are some other ideas I have, which I think can be shared between salt/pepper.
particularly 'calibration'.... it became evident to me with salt, that if you need precise inputs and outputs, really you need to have a calibration file, which can handle scaling … as no 2 salts will be identical.
and pepper is going to need this even more... as is already stated in the build guide, the voltage dividers will never be precise.
really this is no different from any other digital eurorack module - everyone I have, has to have some kind of calibration routine (and are usually 'factory calibrated) to overcome these differences, and also things like PSU differences - so its no 'fault' in salt/pepper rather its the nature of the beast.
finally , why is pepper/salt different from Bela, why these changes?
- Bela is mainly targeted (imho) as an instrument building tool, you have to make the hardware, and you are going to write custom software for it.
- Salt/Pepper are 'utility' eurorack modules - like O&C, ArdCore, Terminal Tedium, these could potentially be used directly by end users - if we share patches etc. it could be really cool to build a small community around them
(p.s. this is also why I think patch swapping is pretty important)
so I think whilst technically similar, I think the market and potential is quite different...
I also think this area needs a bit of 'encouragement' to get started...
Ive got a Qubit Nebulae2, and noticed with it - that the community dev aspect is a bit 'lacking', because whilst qubit have made it possible for custom patches, its not really supported well...partly because it lacks a forums, and everything (support, use as is, development) is chucked on one muffwiggler thread, which leads to frustrations between different types of users.