SamIAm

S'manth x 😉

Not as far as I am aware S'manth x

It is quoted as 48kHz. And I belive the 8ms is roundtrip latency, based on a pedalboard setup that routes the input directly to the output. Interesting topic ... I imagine that different plugins will add aditional unwanted delays, I shall have to whack a scope on mine and see what the measured latency is for the pedalboard config I use ... S'manth x

From what I have been able to glean, it is single digit ms ... circa 8ms. This MOD forum post has some results (that I do not fully understand!). Of note is that the user had their device set at 128 (bit I presume) sample size. It is possible to run the Dwarf at 256bit samples, the disadvantage is an increase in latency ... but it reduces the CPU consumption ... handy when one is running a super complex pedalboard layout. On a different (but hopefully useful) topic, MOD have an online playground to let you try out their GUI ... https://try.mod.audio/?v=1683140283 to see its power and if you like it (or not) S'manth x

Might be worth checking this thread over on the MOD forum where people share their various setups. S'mant x

On the first Tuesday of the month I attend a ukulele jam. Tonight was the first time I took my “proper” rig along, it behaved well. The battery powering my pedalboard dropped from 100% to 90% over the two hours, well pleased. S’manth x

A community without a doubt. Last year a fire in my flat took most of my earthly possesions, including anything to groove on. I reached out and in just a couple of weeks the lovely folks here had got me back playing by sending various bits of bass gear ... I will never forget their kindness ... if not a community, this would not have happened! S'manth x

Progress ... Wired up my buttons with a long cable so I can connect it to the prototyping breadboard my PICO lives on. Managed to integrate FreeRTOS so that now all activities are multi threading, it was not as fiendishly difficult as I feared ... the code was very straightforward, the CMake configuration took much longer. I've now got a system that will print when it detects button presses, a hop skip and a jump away from being able to fire off simple MIDI control messages. Then the logic to properly debounce the buttons as well as detect single/double/long taps. S'manth x

I'm interested to see what you find. I think that CC devices can get info out of the Dwarf that a MIDI pedal cannot, which could be handy. Both CC and MIDI assignments are done in the Web GUI. I'm unclear as to how one would configure the CC device itself, for example ... can a CC button be setup to do different things for single/double/long taps? One (annoying!) constraint of MIDI on the Dwarf is that a particular MIDI message seems to be only assignable to a single plugin parameter, thus to drive different plugins a controller button needs to be able to send multiple MIDI messages (I have pondered writing a plugin that would recognise a particular MIDI message and then send out one or more, sorta like a MIDI multiplier/macro/translator thing ... but I've yet to get my head around LV2 development!), I wonder if CC is more flexible. S'manth x

I'm sure there are at least four of us here who have a MOD device, I've seen @andybassdoyle (Hiya Andy 👋) posting over on the MOD forum. S'manth x

Pedalboards tend to take a non trivial time to load, I think it is because for each plugin the MOD ecosystem creates a new Jack client ... snapshots load much quicker. This has led me to using fewer pedalboards, which have more plugins ... then changing the on/off status (or even routing) using snapshots. S'manth x

I think then in Navigation mode (The one wherre you can select pedalboards/snapshots) on the Dwarf, a button allows you to select a bank which then changes the set of Pedalboards that appear in the list ... I think! S'manth x

@Woodinblack pix of your setup (or it doesn't exist ... according to BC lore) 🤣 Glad it went well! S'manth x

Mostly been working on some houskeeping. I "think" I've got the Cmake configuration sorted (I'm new to writing CMakeLists so it's been ... fiddly!) It has been a couple of years or so since I last used VSCode in anger (And that was for TypeScript work) ... I've been adding in all the nice extensions/settings that I like (eg Rainbow Indent, Git Lens, Error Lens, Commitizen, Better Comments) I'm sure I've missed some but my dev environment is now humming along nicely. At some point I'll need to eat the frog of getting the debugger working ... but not just yet! I've done the first checkin of the codebase to git. (My intention is to share this once I've reached a MVP). The PICO SDK can automagically hook up printf etc to the serial output to make debug printg easy ... however ... when this approach is used, it it rather selfish and will not let other play with the USB and this is incompatabile with my USB for Serial and MIDI approach. So I've written a crude but effective wrapper around sprintf and serial send to allow me to achieve a serial printf. It's been my first forray into variadic functions. Following on from the link that @tauzeroshared about easy button debouncing I stumbled across http://www.ganssle.com/ which has a wealth of information on writing code on embedded systems. After a bunch of reading I am going to try to incorporate FreeRTOS into Trampa to keep the architecture simple. It provides a widely used, robust and very tiny kernel that supports multitasking (including multicore!) with the stuff that makes it easy like queues, semaphores, mutexes etc. It also has a set of libraries that bring in stuff like Http (when and if I reach the Trampa web based config functionality). So my next goal is to convert my current "MIDI Note Player with Serial Debug Print" example so that it runs under FreeRTOS. Fingers crossed ... S'manth x

The wise wise words of one who has been there and done that! S'manth x

Yes, something in the OLED code was mocking me! 🤣 There are a few button libraries I came across for the Arduino environment, my favorite was https://github.com/bxparks/AceButton#readme tho http://www.mathertel.de/Arduino/OneButtonLibrary.aspx has a rather nice FSM flow I'll probably end up adapting (as I want to drive the button detection system using H/W interrupts and I also would like to be able to detect when two buttons are held down together). There are also some inspiring ideas in the app I used for my first MIDI controller build https://github.com/alf45tar/PedalinoMini#pedals You are spot on about the inherent delay when a button is configured to be able to detect single/double/long tap. In some use cases (like toggling on/off an effect or loading snapshots) I'm not sure if it will be long enough to be a problem ... I'll need to have a play with the timings, but I've seen values ranging from 250 to 500ms used to determine if one is double tapping and perhaps 1,000 to 1,500ms to detect a long tap. For looper control (or tap tempo) type situations where this is an unacceptably long latency, I envisage that a button can be configured to be single press only, if configured for single-press-latching, it will send a MIDI-ON or MIDI-OFF message on alternate taps; if configured for single-press-momentary it will (optionally) send a MIDI-ON message when pressed and (optionally) a MIDI-OFF message when released. I would guess that this could drop the latency to double digit ms (Tho this is just a stick my finger in the air kind of guesstimate 🤣) tho I will need to consider how to ensure any debounce logic does not delay this. ** MIDI-ON & MIDI-OFF will be configurable to be any MIDI message the user desires (or even sequence of MIDI messages). ** I'm scouring the Morningstar user guide as they have some nice ways of representing the different event types that can be generated https://morningstarengineering.atlassian.net/wiki/spaces/MMS/pages/181698574/Action+Type+List tho I'm also looking at the stuff by https://piratemidi.com/ for inspiration. S'manth x

Cool! I'm taking an interrupt driven approach to IO (buttons/expression pedal/midi/http) driving fifo queues to try to improve responsiveness and hopefully allow easy(ish) multicore division of labour (well, that's my hope!) ... I'll have a look at the code you kindly sent to see how I can adapt it to this approach. S'manth x

I was sorta hoping for something more like ... 🤣 S'manth x

Brilliant! S'manth x

There are some things that are pretty much a given when developing software, a couple of them are: 1) Theft - OK, so we call it reuse! (In the open source world this is encouraged, generally all one needs to do is acknowledge the original genius who's work you are stealing reusing. It is actually a practical example of the quote “If I have seen further, it is by standing on the shoulders of giants.” - Isaac Newton. 2) Debugging - Once a section of code is written, compiled and run ... it goes off and does what you have told it to do, very occasionally this is what you actually intended ... but more often than not it isn't! When faced with the near certainty of impropriety it is useful to be able to observe what the code is actually doing. With the development environment I'm using for Trampa, there is a rather sophisticated debugger (A tool that lets you progress through a program one line at a time, examine and change the values of variables, etc) available, but I've yet to have a good play with it (It actually consists of a second PICO running some special software and wired in a special way to the PICO that the software being developed runs on). For now I'm doing some simple debugging by scattering print commands throughout my code, this will display messages like "You are here", "This is is the Nth time we have reached this point", "I have just received a MIDI message [CC 0xed]" or "You really don't know what you are doing ... do you!?". Applying these two "principles" I have reached a minor milestone. 🥳 I was able to find a good example of how to send MIDI messages from Trampa to my laptop (Over a USB connection). When I run this example, I can see (Using a MIDI monitor on my laptop) the MIDI messages coming in the USB port and if I fire up a DAW (Logix Pro in my case) I can hear notes being played. I have also found some examples of how to print messages via the USB connection such that they appear to come in via a serial connection on the laptop and can be displayed in a terminal emulation program, this will let me keep an eye on things. But ... both the MIDI and the Serial run over the same USB connection and ... darn it ... I searched high and low but I just could not find an example that showed how to use them both together (I knew it was possible as I have done it using a different programming environment) using C++ and TinyUSB (Which is what I'm using). Over the course of several hours I have tried one approach after another ... without any joy, I could get MIDI to work but the Serial would remain sullenly inoperative ... or vice versa. When Trampa is running for real I won't need the serial print capability, but whilst I'm developing it ... it will be essential to allow me to see what the system is doing with respect to reading incomming MIDI messages or detecting the different types of button presses for instance. And then I stumbled across an example that seemed promising, it had a name that was in no way connected to what I was trying to achieve, I had found no handy "Here is how I did it" articles on the web, I just knuckled down and poured over the source code of several dozen different examples and tried tweaking some of them ... but it eventually bore fruit! I now have a very simple example program which can send MIDI message to the laptop and send the output of my print commands to a terminal emulator! (I have to admit I did a little dance of joy when it worked ... yes I've a sad life 🤣) Next in the ever growing list of things to bite off, is the ability to detect the different types of button presses (Press/Release/Single Tap/Double Tap/Long Tap). There are a few really elegant libraries that provide these sort of features, but I've yet to find a good one using the C++/PICO_SDK setup that I have chosen ... I cannot believe I'll not find one, but haven't yet. Once I can detect the button presses I can then generate different MIDI messages based on which button is pressed (and the type of press) and even tho the displays won't be working I will have actually have a basic MIDI controller! More developments as they occur ... S'manth x

Your are right @Woodinblack, I've cheap OLEDs which have a fixed address. I gather that it is possible to bitbang I2C to allow the use of non h/w I2C pins, which would allow for more displays, but I took the approach @tauzeromentions ... it is not difficult to use and allows up to 8 devices (I'm unlikely to need more than 5 at the moment). I did however find an odd issue when using the Arduino OLED libraries (during my proving out stage) that there was what appeard to be some ... 'crosstalk' between the 128x32 (4 of these) and the 128x64 (1 of these) that caused the 128x64 to expand fonts vertically by a factor of 2! I combed thru the code several times to ensure I was using totally seperate variables/objects but I could not resolve it (the actual text displayed on each OLED was unique as intended). When I get to driving them from c++ I may have to figure out what was actually going on. S'manth x

Just a geek with some software and electronics experience and a love of gadgets. Hope to produce (eventually) a build guide for those who might want to do similar. S’manth x

I went for MIDI as the MOD Control Channel is not as mainstream, in theory I could use Trampa to control a Zoom pedal (Tho the USB hookup is quite different and the Pico needs to run in USB Host mode, which I believe the TinyUSB library I'm using supports), when I get Trampa working I may see if the control channel is easy to add. My expression pedal is analogue (A foot operated potentiometer). The pico has 3 onboard ADCs and I'm using one to read the value from the pedal (It comes back as a value from 0 to 1023) and then mapping this onto the 0 to 127 range for a MIDI CC message. S'manth x

By "bank" I mean the set of values that will be sent by buttons. For example, with the MVave setup to use Program Change A, it starts up in Bank (They may use the phrase group) 1. Button 1 will send a PC 0 message, Button 2->PC 1, and so on. If you depress Button 3&4 simulatneously, the MVave will page up a bank/group, so that Button 1 will send PC 4, Button 2->PC 5, and so on. Pressing Buttons 1&2 simulataneously will go down a bank/group. There are multiple banks/groups so by paging up and down one can achieve many more than 4 different MIDI messages. Sadly however, it does not appear that this can be used to send CC messages, which is what I gather the Dwarf wants to activate/deactivate plugins, etc. The MVave mode I use only lets one configure for the four buttons, there seems to be no ability to use the banks/group concept. There is a nifty writeup thread over on the MOD forum. S'manth x

I've got my MVave configured in custom control mode, where each footswitch sends a specific CC with alternating 0/127 value. I use 1,2,3 to toggle on/off effects (Octave/Fuzz/Reverb) and 4 to start/stop the MIDI player. I've not found a way to use the MVave mode that allows for bank switching to drive my Dwarf (This is why I'm building my own). MY MVave is connected to the Dwarf via a USB cable. This is the pedalboard I'm tinkering with at present. S'manth x