R

red_tin_dave

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?

PatchStorage has the closest thing to a wiring diagram. This project gives the general idea that you can modify to match the specific description below:
https://patchstorage.com/dynamic-range-compressor-feedback-topology/
Of course, the above project works as advertised if all you wanted was a dynamic range compressor.
Based on the same wiring diagram, here are some other "broken out" effects that will work on the same wiring diagram:
https://github.com/transmogrifox/Bela_Misc -- specifically "overdrive" and "klingon-tone"

The interface for the whole FX processor is a bit crude for now since I currently depend on the console output to see which effect and parameter are being adjusted.

Here is the most current code for the project:
https://github.com/transmogrifox/transmogriFX_bela

Here is some code that can help get started implementing LCD output and control if you want. Code I haven't pushed to gituhub implements some rudimentary I/O on the LCD so I'm not working totally blind without a computer connected to the IDE, but not good enough to push the code at this point. The audio level meter code has all the pieces needed to design a usable LCD interface.
https://github.com/transmogrifox/Bela_Misc/tree/master/audio_level_meter

The short description is this:
-- Connect 6 pots (10k) between ADC ref pin and gnd with wipers going to Analog input channels 0-5.
-- If you have a wah pedal, disconnect the pot from the wah circuit and connect the pot between ADC ref pin and ground with wiper going to Analog input channel 8.
-- Connect 420 to 500 ohm resistor from 5V to Analog ref pin to make up the extra current drawn by the 10k pots. If you use 100k pots, then the resistor to 5V can be the 4.7k shown in the compressor diagram.
-- Connect bypass pot to digital input 4, switching between 3.3V and GND.

Then for switches, connect either:
1) Normally closed momentary pushbutton switch between digital input pin to ground with 3.3k pull-up resistor to 3.3V.
2) Normally open momentary pushbutton between digital input pin to 3.3V and 3.3k pull-down resistor to ground.

Here are the definitions for what switch channels to use and what they do:

//Control context 
#define CONTROL_CONTEXT_SWITCH	3  //input 0 appears to be dead on dev's unit (maybe ESD? or just broken wire)
#define CONTROL_EFFECT_SWITCH  	1
#define EFFECT_BYPASS_SWITCH	2
#define WAH_PEDAL_BYPASS	4

I was using digital input channels 0-3, but one was broken so I am using 1-4. As the code is written:
Digital input 1: Scrolls through list of FX, makes them active for control. (CONTROL_EFFECT_SWITCH)
Digital input 2: Toggles on/bypass state of active effect. (EFFECT_BYPASS_SWITCH)
Digital input 3: Scrolls through control pages on the effect, which assigns the pots to different sets of parameters.(CONTROL_CONTEXT_SWITCH)
Digital input 4: Logic high (3.3V) wah is activated unconditionally, Logic low wah can be switched on/off with EFFECT_BYPASS_SWITCH if wah is the active effect selected by CONTROL_EFFECT_SWITCH.

From there the audio path is intended to work like this:

{Guitar} ----->[Bela CH0 IN] ...[Bela CH0 OUT] -->{External FX Chain(FX send/return)}--->[Bela CH1 IN]...[Bela CH1 OUT--->{Amplifier}

Here are some hardware interface circuit ideas, but there is no PCB layout nor BOM:
https://github.com/transmogrifox/Hardware/tree/master/Bela_Input_Buffer

The user interface to this is very crude but all the pieces are there to build a nice FX processing unit. My plan is to abandon the current "render.cpp" and start over from scratch but at my current rate this will be a project of many years.