• HardwareEurorack

  • New products: Pepper and Salt, two ways to bring Bela into Eurorack

hmmm. those could cause troubles for the analog inputs/outputs. You could start off by installing only a couple of pins and see if you get a good connection. A trick to get a bit of extra length is to push the pin into the PCB so that it is flush with the soldering side of the PCB. Then, add solder there. If you get the solder to flow through the plated-through holes then you are good. (note that this may require sliding the plastic a bit further down to provide more stability when soldering, but it should be doable)

5 days later

I'm about half way thru building two peppers 🙂

though, Ive come to a bit of a halt as I'm waiting for the 8mm headers to turn up - could be another week 🙁 ,
(decided not to risk bad connections as they would be very difficult to get in to replace once pots/jacks are in place)

it's a nice straightforward build so far, and for a eurorack project - lots of room to work with.

one thought, it be really handy to have an 'example' project that was a 'tester', to allow you to confirm the build was working quickly/easily.... preferable initially over USB , so you can initially test outside your eurorack.
(it'd also serve as an example on how to use everything)

I was thinking something like:
connect all outputs (audio and cv) to corresponding input,
then outputs could put out a known voltage/signal, that can be measured by the inputs. and assuming all is ok, then the LED would light up. (10 leds = 8cv + 2 audio)
(perhaps >40% signal = ok, to allow for different voltages depending on usb or eurorack power?)

perhaps then use the button as 'back/forward', and it would cycle through each of the signal level on the input, thus when you turn the correspond pot, you'd see the attenuation.

its not an exhaustive test, but covers the main test cases - the rest you'll spot once you start using it.

btw: do you think it might be an idea to have pepper a bit like salt, i.e. a 'make_peppery' step?
in particular im thinking of having patch change based off one of the buttons held down like salt.
(I find this really useful on Salt... as i tend to switch between 2 or 3 patches - which have a different initial LED set, so I can see which one is loaded 😉 )

    thetechnobear one thought, it be really handy to have an 'example' project that was a 'tester', to allow you to confirm the build was working quickly/easily.... preferable initially over USB , so you can initially test outside your eurorack.
    (it'd also serve as an example on how to use everything)

    Good idea. We have a Salt test patch in the Extras/ folders in examples, that could maybe be repurposed. Or maybe it's not so easy.

    thetechnobear make_peppery' step?
    in particular im thinking of having patch change based off one of the buttons held down like salt.
    (I find this really useful on Salt... as i tend to switch between 2 or 3 patches - which have a different initial LED set, so I can see which one is loaded 😉 )

    Probably could be done, however I am not sure how to best generalize it. Currently make_salt.sh does little more than copying these files to the file system, to assign a GPIO pin to kill the program. It also does another thing: it sets the board to be Salt. This is then used by the Bela core code to determine whether to invert the analog and digital I/O. This is required by the active electronics of Salt, but should not be done for Pepper.

        Hey Mark, you didn't happen to create a mouser BOM for the parts did you?

        It certainly does, thanks.

        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
        -DBELA
        -DSALT
        -DPEPPER

        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.

        thoughts?

          9 days later

          @giuliomoro , could you add the pepper examples to the main Bela repo examples?
          I’ve chucked them in manually, but it’s not easier if my Bela repo stays in sync with the main one?

          Btw: generally if you let me know which ideas you are in favour of, then once done I can send you a PR - otherwise i’ll do in a different repo of my own.

            thetechnobear , could you add the pepper examples to the main Bela repo examples?
            I’ve chucked them in manually, but it’s not easier if my Bela repo stays in sync with the main one?

            We have a major update coming out in a few weeks, with libraries support, GUI and a new IDE. At that point we will also add Pepper patches.

            thetechnobear one thing I would really like is for the 'make system' to automatically add a
            -DBELA
            -DSALT
            -DPEPPER

            BELA is true in all cases, as SALT and PEPPER are derivatives... but help my cross platform code.

            I'd be more in favour of runtime checks+calibration file rather than compile-time defines at the moment, because that's what we do for all Bela/Mini/capelets/CTAG at the moment. You can already detect the board at runtime by calling BelaHw Bela_detectHw() from setup(). There is no detection for Pepper yet (that would probably have to go through a manual BOARD=Pepper in ~/.bela/belaconfig, but it also requires support from the backend code). I agree that supporting the different configurations of Pepper is a bit complicated (it's not just analog/digital, but HOW MANY digitals you have, and then what voltage ranges on the analogs?).

            Can you show an example of code where compile-time would be a significantly better option [maybe in a dedicated forum thread]?

                  giuliomoro

                  the one time where preprocessor directories are more useful is when defining constants which can be used in array boundaries and also the compiler can optimize constants.

                  but honestly, that just how I wrote the code because I used #defines. I'm sure I probably won't loose that much by using Bela_detectHw() and by using non constants.

                  heres an example...

                  #ifdef SALT
	static constexpr float 	OUT_VOLT_RANGE=10.0f;
	static constexpr float 	ZERO_OFFSET=0.5f;
	static constexpr int   	START_OCTAVE=5;
#else 
	static constexpr float 	OUT_VOLT_RANGE=5.0f;
	static constexpr float 	ZERO_OFFSET=0.0f;
	static constexpr int 	START_OCTAVE=0.0f;
#endif 
	static constexpr float SEMI_MULT = (1.0f / (OUT_VOLT_RANGE * 12.0f)); // e.g 1.0 = 10v = 10 octaves 
	float transpose (float pitch, int octave, int semi) {
		return (pitch + semi + (( START_OCTAVE + octave) * 12.0f )) *  SEMI_MULT ;
	}

                  so v/oct , for salt 0.1 = 1v since its 10v range, but for bela/pepper 0.2 = 1v
                  the reason I use constants is this way the code can remain readable, but I would expect the compiler to optimize SEMI_MULT to a fixed value.

                  this is getting called on once per render (as its a control value), but really I don't think its going to chew much cpu, so it probably be fine if it was non constant due to not be done by compiler?!

                    giuliomoro We have a major update coming out in a few weeks, with libraries support, GUI and a new IDE. At that point we will also add Pepper patches.

                    What are the IDE changes?

                      Improved design, new ace.js, behind-the-curtain refactoring, some long-standing issues fixed, but mostly it's an excuse to add support for libraries and GUI.

                      What do you mean by GUI, is this a way of making an GUI in the web interface?

                      yes! You may have seen them already at Brighton modular

                      I didn't manage to make it to Brighton, I'm looking forward to seeing what you have come up with...