<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My main concern right now honestly is figuring out a chip that is<br>resilient enough to attack to allow for 10 years of security with<br>rolling updates. I don't really know enough about how those things<br>work. Can such chips be programmed with my own secure cryptographic<br>algorithms, without exposing power sidechains? Can I limit the amount<br>of challenge-responses per second? Can I program the chip with a<br>secure VM?</blockquote><div><br></div><div>- 10-years strikes me as very unrealistic.</div><div><br></div><div>- You can buy tamper-proof/evident/whatever CPUs.  Although possibly not in small qty.  They'll run whatever fits into them.</div><div><br></div><div>- Not leaking data via power, timing, whatever is up to you.  </div><div>   For known attacks, the hardware crypo coprocessors will be resilient to that sort of thing, but it's still up to you to write balanced code that has uniform timing & power consumption.  For example, if you quickly determine some action is unauthorized, don't stupidly respond right away ... finish the exact same work you'd need to do as though everything was properly authorized.</div><div><br></div><div> - Challenge/response rate is a commercial decision, not technical.<br></div><div><br></div><div><span style="background-color:transparent">- "program the chip with a secure VM".  I'm not sure what "program" means in this context. <br>  a. Set values in the chip's flash by running code in a VM (ex. VM == docker).</span></div><div><span style="background-color:transparent">  b. The assembled code that the cpu is executing is something like your "encrypted execution machine".</span></div><div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent">In either case, my gut feeling is "no".  If it's (a), any software you execute on an insecure CPU is insecure.  If it's (b), what's the point?  You already purchased a secure CPU, what does this extra level of complexity get for you.</span></div><div><span style="background-color:transparent"><br></span></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">connect a usb cable and click a button on a website</blockquote><div>This suggests each secure chip needs to have enough memory to store a potentially *very* large list of bad modules.  You'll need to find a way to keep that list small.  You can store databases on an untrusted device, but it's tricky.  Actually works a bit like your maldboge idea where you're hiding data in random accesses plus you'll need to waste a ton of bandwidth to hide your memory access pattern.  There may be patent issues with these kinds of systems; it's been a few years since we investigated that type of approach ... ultimately the bandwidth requirements weren't compatible with other latency requirements.   Safest approach is to store what you need in the memory of the secure cpu and/or stream the entire encrypted 'deny' file through the secure cpu.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Steam knows which people pirate games, and they still don't do anything, because it's just not worth it from the business point of view.</blockquote><div>This goes back  to your original "piracy is a customer service problem".  As you're proposing, cloning is the same.  You think your products will underperform in the market relative to large manufacturers, so you're attempting to force the consumer's hand through a DRM scheme.  Might be better business to offer really good customer service instead.</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 10, 2026 at 10:49 PM cheater cheater <<a href="mailto:cheater00social@gmail.com" target="_blank">cheater00social@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I agree that online auth might be necessary, at least every now and<br>
then, possibly when a new device is connected to the modular system.<br>
Given that people don't change modules a lot, it wouldn't be much of a<br>
hassle, and they're already elbows deep in grease so it's not like<br>
they're technically inept to connect a usb cable and click a button on<br>
a website. However, given that people also keep upgrading modules, if<br>
they continue upgrading, any time they re-auth, their repudiation list<br>
would get updated. So either you keep using old bootleg devices, or if<br>
you want to use newer devices that have been issued more recently than<br>
the bootleg key, you have to upgrade your modules, and then that locks<br>
out the bootleg devices. This is basically the playstation firmware<br>
upgrade security pattern: new games don't work with old firmware,<br>
exploits don't work with new firmware. 99% of all people don't bother,<br>
but rarely people will buy playstations and just keep them in the box<br>
and wait for an exploit, at which point they get access to some games,<br>
but that won't even work here: the attractiveness of playstation<br>
piracy depends on the fact that once you have a hacked console, the<br>
games are essentially free; in this case, new modules still cost the<br>
same money; additionally, even if you have a set of older modules that<br>
don't know a bootleg module is bootleg, the other, newer modules will<br>
still reject it, so you're still stuck just using old modules that<br>
haven't been updated. So to use your bootleg modules you'd have to not<br>
just "crack" the older modules, but you'd also have to "crack" the<br>
newer ones as well, and every time you want to add a new non-bootleg<br>
module, you'd have to wait for it to get "cracked". So it's not very<br>
practical for the person using the bootlegs. Meanwhile, for the<br>
bootlegger, every time a key gets repudiated, they would have to<br>
obtain a new key. This shouldn't be easy, and would essentially<br>
require an existing approved manufacturer (or other entity in the<br>
supply chain) to sacrifice their business and licensing in order to<br>
provide the bootlegger with the key. (they could argue being hacked,<br>
but that's not a feasible explanation in the long term)<br>
<br>
Meanwhile Steam uses minimal DRM and while people do pirate Steam<br>
games, most don't bother, and the business can survive pretty well,<br>
i.e. the opposite to audio hardware manufacturers, who struggle. In<br>
fact, Steam knows which people pirate games, and they still don't do<br>
anything, because it's just not worth it from the business point of<br>
view.<br>
<br>
Regarding modulation, it would be pretty difficult to remove it to<br>
satisfactory quality. Maybe some other in-band signal can be used,<br>
idk. I'm trying to come up with something that doesn't mess with the<br>
sound during playing. Preferably at time of initial connection.<br>
<br>
One thing I am painfully aware of is the concept of session hijacking.<br>
Essentially, if only a handshake is used to secure a connection, but<br>
later communication is in plaintext, then the initial handshake can be<br>
forwarded to the unwitting legitimate module, while later<br>
communication happens with the bootleg module. One example where this<br>
is known in hardware are bootleg game cartridges. Each console<br>
required each cartridge to contain a lockout chip (known as the CIC<br>
chip). So what bootleggers did was a system where you'd have a "pass<br>
through adapter": it was a cartridge that plugged into the console. It<br>
had two cartridge ports of its own, on top, and in the back. You<br>
plugged any old legit game in the back, and that's what answered the<br>
CIC query; the cartridge at the top was the bootleg game you wanted to<br>
play. One weakness of this system was that the legit cartridge, being<br>
used as the handshake patsy, had no idea that it was being used like<br>
that. In a modular system, one could keep track of what's connected to<br>
what, and if there's more than one connection to one port, old<br>
connections get deauthorized and disconnected.<br>
<br>
My main concern right now honestly is figuring out a chip that is<br>
resilient enough to attack to allow for 10 years of security with<br>
rolling updates. I don't really know enough about how those things<br>
work. Can such chips be programmed with my own secure cryptographic<br>
algorithms, without exposing power sidechains? Can I limit the amount<br>
of challenge-responses per second? Can I program the chip with a<br>
secure VM?<br>
<br>
Some time ago I've been looking into secure computation in adversarial<br>
environments, and I've concluded a good design might be a VM inspired<br>
by how Malbolge works, however instead of it having some sort of<br>
unknown cypher* that requires cryptanalysis, the key would be known to<br>
the root of trust, who would be able to encode programs for the VM.<br>
Writing hello world in Malbolge required significant cryptanalysis by<br>
the community.<br>
<br>
* <a href="https://en.wikipedia.org/wiki/Malbolge#Crazy_operation" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Malbolge#Crazy_operation</a><br>
<br>
I think this might be improved if every unit / module has its own<br>
private keys, which are all stored in the CA, therefore key derivation<br>
from any one unit does not transfer to any other unit.<br>
<br>
An additional positive aspect of an encrypted VM is that the program<br>
is essentially random noise, and the execution path is essentially<br>
random as well.<br>
<br>
An encrypted VM is basically explained as follows:<br>
<br>
Normal VM:<br>
new_state = operational_semantics(old_state, opcode)<br>
<br>
encrypted VM:<br>
decrypted_opcode = cipher(concat(secret_key, old_secret_state,<br>
old_state, encrypted_opcode))<br>
(new_state, new_secret_state) = operational_semantics(secret_key,<br>
old_secret_state, old_state, decrypted_opcode)<br>
<br>
Here, operational_semantics() is the implementation of the opcodes,<br>
i.e. it describes what should happen when it sees "mov", "je", "nop",<br>
etc. In the encrypted VM, the opcode is first "randomized"* through<br>
the one-way function (cipher) applied onto the encrypted opcode; then,<br>
the cipher is used to figure out what actual opcode this maps onto.<br>
This means that at every state of the program, to do what you want to<br>
do in the next step, you have to know the factors of the cipher, and<br>
you have to know the secret key, and the current state.<br>
<br>
*from the point of view of an observer who doesn't know the secrets<br>
<br>
The "state" is what the program knows about, it is the combination of<br>
the stack, heap, registers, program counter, etc. The "secret state"<br>
is something the program has no concept of, it is not exposed by the<br>
VM.<br>
<br>
This means that essentially such a VM is impossible to program unless<br>
you are told the secret parameters. If you know the secret parameters,<br>
to you the cipher is compromised, and every time you write a new<br>
instruction for your program you have to essentially "hack the<br>
cipher", which is less difficult than if you didn't know the cipher<br>
secrets.<br>
<br>
> Malbolge is a public-domain esoteric programming language invented by Ben Olmstead in 1998.<br>
<br>
> Malbolge was very difficult to understand when it arrived, taking two years for the first Malbolge program to appear. The author himself has never written a Malbolge program. The first program was not written by a human being; it was generated by a beam search algorithm designed by Andrew Cooke and implemented in Lisp.<br>
<br>
> There is a discussion about whether one can implement sensible loops in Malbolge—it took many years before the first non-terminating one was introduced. A correct 99 Bottles of Beer program, which deals with non-trivial loops and conditions, was not announced for seven years; the first correct one was by Hisashi Iizawa in 2005.<br>
<br>
> In 2020, Kamila Szewczyk published a Lisp interpreter written in Malbolge Unshackled.<br>
<br>
It took 22 years to write a complex program like that in Malbolge.<br>
<br>
Cheers<br>
<br>
On Fri, Sep 11, 2026 at 6:52 AM David Kantowitz <<a href="mailto:dkantowitz@gmail.com" target="_blank">dkantowitz@gmail.com</a>> wrote:<br>
><br>
> How is a compromised module defined & detected?<br>
> How would the repudiation information reach a compromised module? or to modules connected to the compromised module?<br>
><br>
> I'm sure there are complexities, but mixing coded noise into the outputs doesn't seem especially difficult. If the outputs are already digital, then you need to find a synchronization side channel.  If the outputs are analog, modulate sync information in a frequency band outside what you were planning on transmitting ... if you're already satuating the analog i/o bandwidth, then find a different side channel.<br>
><br>
> PS. Note that this doesn't really prevent clones.  It simply makes the new equipment incompatible with everything else.  Which doesn't sound very appealing to me as a consumer, but maybe the easy-to-clone yet intrinsically-awesome capabilities of modules in this new format will change my mind.<br>
><br>
> PPS. If you're depending on modules being connected to the internet for repudiation data, then authorization is what the world generally uses.   Works very well.  Again, consumers generally hate it.<br>
><br>
><br>
> On Thu, Sep 10, 2026 at 9:26 PM cheater cheater <<a href="mailto:cheater00social@gmail.com" target="_blank">cheater00social@gmail.com</a>> wrote:<br>
>><br>
>> While technologically difficult it's also probably satisfactory, but<br>
>> you'd probably need to be able to repudiate compromised devices /<br>
>> licenses as well.<br>
>><br>
>> On Fri, Sep 11, 2026 at 6:19 AM David Kantowitz <<a href="mailto:dkantowitz@gmail.com" target="_blank">dkantowitz@gmail.com</a>> wrote:<br>
>> ><br>
>> > Would this example approach satisfy your needs:  every output is mixed with wide-band PRNG noise and only "in family" modules have the algorithm to filter that noise from their inputs.<br>
>> ><br>
>> > On Thu, Sep 10, 2026 at 9:09 PM cheater cheater <<a href="mailto:cheater00social@gmail.com" target="_blank">cheater00social@gmail.com</a>> wrote:<br>
>> >><br>
>> >> > Honestly, it's a bit hard to point you in the right direction without understanding what you actually want to do.<br>
>> >><br>
>> >> Ultimately the goal is as follows.<br>
>> >><br>
>> >> Situation: A new physical format, let's say for modular synthesizers<br>
>> >> or audio effects, is created.<br>
>> >> Problem: how to lock out a specific manufacturer that clones devices<br>
>> >> created by others, so they don't shit up this format as well?<br>
>> >> Solution: some form of hardware authorization and authentication<br>
>> >><br>
>> >> Purpose of the discussion: The first part can be something myself and<br>
>> >> some others are planning, or it could be something that a completely<br>
>> >> different group of people are doing and they could use what's been<br>
>> >> learned here as basis for safeguarding their business from parasitical<br>
>> >> manufacturers<br>
>> >><br>
>> >><br>
>> >> On Thu, Sep 10, 2026 at 10:02 PM David Kantowitz <<a href="mailto:dkantowitz@gmail.com" target="_blank">dkantowitz@gmail.com</a>> wrote:<br>
>> >> ><br>
>> >> > Not really. Search for "secure microcontroller" at the NXP website.  The detailed manuals (at least for NXP) usually require an NDA w/ NXP, but a 2-page summary sales sheet should be available.<br>
>> >> ><br>
>> >> > A lot of microcontrollers (not just NXP) have features like: 'secure boot', 'secure element', 'secure memory', 'trusted module', 'trusted execution', etc.  ARM has TrustZone that a lot of manufacturers use.  Some combination of those features could do what you want.<br>
>> >> ><br>
>> >> > Honestly, it's a bit hard to point you in the right direction without understanding what you actually want to do.   ... and based on my earlier emails, what you described as wanting to do doesn't really make sense to me in a commercial context.  There are significant costs involved in building even vaguely secure hardware.  An example of the stupid shit that happens ... units were keyed at Key Injection Facility, then shipped to the user site, units started to arrive in the tamper state with no keys .. queue 6 month parade of units back and forth ... eventually we figure out that a software bug wasn't putting the cpu into a low enough sleep state and the supercap keeping the keys alive was drained in transit.  I can't even bear to describe how stupid the spares situation became.<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > On Thu, Sep 10, 2026 at 11:51 AM cheater cheater <<a href="mailto:cheater00social@gmail.com" target="_blank">cheater00social@gmail.com</a>> wrote:<br>
>> >> >><br>
>> >> >> Thanks, David. That's some good info. Can you point to some recent<br>
>> >> >> devices that are available on the market?<br>
>> >> >><br>
>> >> >> On Thu, Sep 10, 2026 at 7:22 PM David Kantowitz <<a href="mailto:dkantowitz@gmail.com" target="_blank">dkantowitz@gmail.com</a>> wrote:<br>
>> >> >> ><br>
>> >> >> > BOM cost was single digit USD.  Essentially it was a way to audit licensing fees through an electronic component based supply chain.<br>
>> >> >> ><br>
>> >> >> > What you're describing are key rolling and key injection.  You can look at current practices for payment terminals, but honestly those are made-by-committee unions of the individual company's own practices.<br>
>> >> >> ><br>
>> >> >> > We used two basic approaches to secure the cryptographic root:<br>
>> >> >> >   1. 'Base' key injection key that's used only to load site-deployment keys.  Those keys were secured by obscurity.  "Steganographic methodology" when we wanted to sound like experts.<br>
>> >> >> >   2. Shipping units to a secure key injection facility.  Use tamper evident bags when you want a fancy audit trail.<br>
>> >> >> ><br>
>> >> >> > Site keys are stored in something physically tamper-proof.  As a simple example (ie. what was done 20 years ago):<br>
>> >> >> >   - make a PCB sandwich.  all components on inside, no traces on outside of PCB.  single power & serial port on outside. a plastic ring goes around the edge. bolot he sandwich together.<br>
>> >> >> >   - electrical connection between the two boards via pin headers<br>
>> >> >> >   - put key in static RAM (not flash, not DRAM)<br>
>> >> >> >   - SRAM on board A, battery on board B<br>
>> >> >> > If someone opens the sandwich and the site keys lose power.  Back to (1) or (2) above to restore site keys.<br>
>> >> >> ><br>
>> >> >> > Despite having microcontrollers with secure memory, much more physically complicated versions of the sandwich are still used today:<br>
>> >> >> >   (A) Detect the tamper.  (B) Destroy the keys.  (C) Restore the keys.<br>
>> >> >> ><br>
>> >> >> > Separately, everyone also builds in some method for key-rolling into their systems.  This handles the scenario you described: you believe the keys were actually stolen with malicious intent.  Personally, I've gone through customer witnessed testing of the key rolling, I've never seen a live system do a key roll.  It was simply too risky.  Instead we would maintain blacklists of cards & equipment.  This requires a system that is frequently online.<br>
>> >> >> ><br>
>> >> >> > On Thu, Sep 10, 2026 at 9:20 AM cheater cheater <<a href="mailto:cheater00social@gmail.com" target="_blank">cheater00social@gmail.com</a>> wrote:<br>
>> >> >> >><br>
>> >> >> >> I agree that the DRM is just one component of an otherwise healthy<br>
>> >> >> >> business strategy.<br>
>> >> >> >><br>
>> >> >> >> Do you remember how much roughly the NXP chips added to your BOM?<br>
>> >> >> >><br>
>> >> >> >> > This seems to be the arc of most cryptographically enabled DRM.<br>
>> >> >> >><br>
>> >> >> >> I agree. I know about power monitoring, power glitching, and various<br>
>> >> >> >> other hardware attacks.<br>
>> >> >> >><br>
>> >> >> >> One thing that I'm curious about is things like updating encryption,<br>
>> >> >> >> in order to be able to repudiate compromised keys, eg from<br>
>> >> >> >> manufacturers who have decided to start leaking them to companies who<br>
>> >> >> >> shouldn't have them. This would at least require some sort of secure<br>
>> >> >> >> vault with a machine of some sort inside, probably a VM.<br>
>> >> >> >><br>
>> >> >> >> Cheers,<br>
>> >> >> >> D<br>
>> >> >> >><br>
>> >> >> >> On Thu, Sep 10, 2026 at 6:09 PM David Kantowitz <<a href="mailto:dkantowitz@gmail.com" target="_blank">dkantowitz@gmail.com</a>> wrote:<br>
>> >> >> >> ><br>
>> >> >> >> > The closest "on topic" experiences I have are with the contactless payment (and ID) cards.<br>
>> >> >> >> ><br>
>> >> >> >> > To read/write Mifare cards, we had to include the Philips (now NXP) reader chip in our equipment: even though our own DSP/FPGA generated the RF modulation signals and we had our own implementation of the on-air data protocol stack.<br>
>> >> >> >> ><br>
>> >> >> >> > All the Philips chip contained was their proprietary shared-secret encryption algorithm.<br>
>> >> >> >> ><br>
>> >> >> >> > Two things happened over time:<br>
>> >> >> >> >   1. Researchers reverse engineered/discovered and published the exact proprietary cryptographic algorithm.<br>
>> >> >> >> >   2. Various key recovery techniques were possible through either defects in the protocol implementation or techniques like power monitoring (which you can also think of as an implementation defect).<br>
>> >> >> >> ><br>
>> >> >> >> > This seems to be the arc of most cryptographically enabled DRM.<br>
>> >> >> >> ><br>
>> >> >> >> > The Philips chips were generally easy to use and the integration cost was more a one-time expense.  Still they added to the BOM cost.<br>
>> >> >> >> ><br>
>> >> >> >> > Even after the system was broken we continued to use them: it was the easiest way to vouch to our customers that our equipment was compatible with Mifare cards.  That compatibility was necessary because, by then, out customers had money sunk (ie. millions) into cards.<br>
>> >> >> >> ><br>
>> >> >> >> > Briefly off topic: that 10+ year experience taught me that DRM-like capabilities are small (nearly irrelevant) technical components in a broader commercial strategy ; figure out the strategy first and then use DRM as a temporary stepping stone in that strategy.<br>
>> >> >> >> ><br>
>> >> >> >> ><br>
>> >> >> >> ><br>
>> >> >> >> > On Thu, Sep 10, 2026 at 12:41 AM cheater cheater via Synth-diy <<a href="mailto:synth-diy@synth-diy.org" target="_blank">synth-diy@synth-diy.org</a>> wrote:<br>
>> >> >> >> >><br>
>> >> >> >> >> David, Mike,<br>
>> >> >> >> >> Please start a separate thread, this isn't what this thread is about.<br>
>> >> >> >> >><br>
>> >> >> >> >> Thanks.<br>
>> >> >> >> >><br>
>> >> >> >> >> On Thu, Sep 10, 2026 at 8:58 AM David Huss via Synth-diy<br>
>> >> >> >> >> <<a href="mailto:synth-diy@synth-diy.org" target="_blank">synth-diy@synth-diy.org</a>> wrote:<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > The idea to do some sort of multichannel modular via digital cables is not exactly new and not exactly something that isn't obvious.<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > Technically such a thing is already done with ADAT/Toslink optical cables and many audio interfaces use it to allow users to add more I/O channels.<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > So the main obvious question is why we haven't seen something like this widely used in the modular world?<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > To me the answer is that the simplicity of the concept is unbeatable: Everything is just a voltage versus time, one signal per cable, what you see is what you get. All while being reliable, cheap to implement, cables are cheap, clocking is not an issue, it is conceptually clear, etc.<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > The two useful applications of multi-channel cables I see are: (1) polyphonic modules where patching up 4+ cables is annoying and takes up valuable panel space and (2) breakout boxes for multichannel connections between racks (e.g. via Ethernet).<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > Of course I could envision cool systems with multi-channel cables, but I am not sure it is really worth the extra complexity to make them digital. By that point one can ask, why not just run everything on a computer and make a patch-cable controller panel that just reads out the patch connections, knob positions etc and controls a big virtual modular.<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > On September 9, 2026 11:44:34 PM UTC, Gordonjcp <<a href="mailto:gordonjcp@gjcp.net" target="_blank">gordonjcp@gjcp.net</a>> wrote:<br>
>> >> >> >> >> > >On Wed, Sep 09, 2026 at 07:31:21PM +0200, cheater cheater via Synth-diy wrote:<br>
>> >> >> >> >> > >><br>
>> >> >> >> >> > >> So, there's good news and bad news. The bad news is that I can't go<br>
>> >> >> >> >> > >> into specifics, but there are good reasons to expect a new modular<br>
>> >> >> >> >> > >> format showing up sometime in the not extremely distant future.<br>
>> >> >> >> >> > ><br>
>> >> >> >> >> > >Good luck with that.<br>
>> >> >> >> >> > ><br>
>> >> >> >> >> > >How did you get one with your polyphonic modular idea with 24 channels of 24-bit 192kHz CV on a single 3.5mm jack?<br>
>> >> >> >> >> > ><br>
>> >> >> >> >> ><br>
>> >> >> >> >> > ________________________________________________________<br>
>> >> >> >> >> > This is the Synth-diy mailing list<br>
>> >> >> >> >> > Submit email to: <a href="mailto:Synth-diy@synth-diy.org" target="_blank">Synth-diy@synth-diy.org</a><br>
>> >> >> >> >> > View archive at: <a href="https://synth-diy.org/pipermail/synth-diy/" rel="noreferrer" target="_blank">https://synth-diy.org/pipermail/synth-diy/</a><br>
>> >> >> >> >> > Check your settings at: <a href="https://synth-diy.org/mailman/listinfo/synth-diy" rel="noreferrer" target="_blank">https://synth-diy.org/mailman/listinfo/synth-diy</a><br>
>> >> >> >> >> > Selling or trading? Use <a href="mailto:marketplace@synth-diy.org" target="_blank">marketplace@synth-diy.org</a><br>
>> >> >> >> >><br>
>> >> >> >> >> ________________________________________________________<br>
>> >> >> >> >> This is the Synth-diy mailing list<br>
>> >> >> >> >> Submit email to: <a href="mailto:Synth-diy@synth-diy.org" target="_blank">Synth-diy@synth-diy.org</a><br>
>> >> >> >> >> View archive at: <a href="https://synth-diy.org/pipermail/synth-diy/" rel="noreferrer" target="_blank">https://synth-diy.org/pipermail/synth-diy/</a><br>
>> >> >> >> >> Check your settings at: <a href="https://synth-diy.org/mailman/listinfo/synth-diy" rel="noreferrer" target="_blank">https://synth-diy.org/mailman/listinfo/synth-diy</a><br>
>> >> >> >> >> Selling or trading? Use <a href="mailto:marketplace@synth-diy.org" target="_blank">marketplace@synth-diy.org</a><br>
</blockquote></div>