<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Ok, it’s not a bug in Mailman, it originates in Sendmail, the service that actually contacts all the other mail servers to deliver the mail. In Brian’s email, the line is truncated after 990 characters. This is conform the RFC 5321 standard, section 4.5.3.1.6 which states that it must be no longer than 1000 characters. (<a href="https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.3.1.6">https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.3.1.6</a>)<div><br></div><div>So Brian’s mail service does not respect this limit, and perhaps it’s not too important nowadays. But the synth-diy server does respect it, and trims the line with an exclamation point and continues on a new line. Unfortunately, the RFC does not specify how to handle longer lines, so at least no information is lost this way. <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">It looks like Sendmail does this for *outgoing* messages only, and that’s the reason the Archive is OK.</span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> </span></div><div><br></div><div>In any case, I’m not going to screw with it. But thanks for the report, I’ve learned something new. Back to your regular schedule of DAC’s and MUX’s. :-)</div><div><br></div><div>Ben (sorry for the admin blabber)<br><div><br></div><div><div><blockquote type="cite"><div>On 10 Dec 2023, at 22:25, Ben Stuyts <ben@stuyts.nl> wrote:</div><br class="Apple-interchange-newline"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><duh> I see it in my email too. I was looking at the wrong part.</duh><div><br></div><div>So it’s not in the archive, and several others have chimed in that they’ve seen it too. So it’s probably for everyone. I see that this occurs inside rather long lines, so perhaps it’s some sort of buffer length limitation in Mailman. I’ll have a look…</div><div><br></div><div>Ben<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 10 Dec 2023, at 20:28, Mattias Rickardsson <mr@analogue.org> wrote:</div><br class="Apple-interchange-newline"><div><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den sön 10 dec. 2023 19:31Ben Stuyts <<a href="mailto:ben@stuyts.nl">ben@stuyts.nl</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-break:after-white-space"><span style="">Hi Mattias,</span><div style=""><br></div><div style="">Is this is the message you are quoting? <a href="https://synth-diy.org/pipermail/synth-diy/2023-December/132104.html" target="_blank" rel="noreferrer">https://synth-diy.org/pipermail/synth-diy/2023-December/132104.html</a> If so, I do not see it in my copy of the message, nor in the Archive. So it could be something in your mail client? Or forwarder? ;-)</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Touché!!! :'-D</div><div dir="auto"><br></div><div dir="auto">/mr - not referring to the Buchla </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-break:after-white-space"><div style=""><br></div><div><blockquote type="cite"><div>On 10 Dec 2023, at 13:03, Mattias Rickardsson <<a href="mailto:mr@analogue.org" target="_blank" rel="noreferrer">mr@analogue.org</a>> wrote:</div><br><div><div dir="auto">[snip]<br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">PS: on the topic of strangenesses in emails, what's the cause of the inserted [exclamation point + newline + whitespace] in long paragraphs? See:</div><div dir="ltr" class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">... as a message comes in, rather than a DAC that needs a continuous data stream (usually fed from a waveform buffer). DAC chips that operate on a fixed sample rate require a clock signal as part of the serial bus that they use, whereas DAC chips that are flexible about fixed or variable sample!<br>
rate do not need a clock, per se, because they have a "convert" signal to load each new value. There is clearly some overlap in the design here, but the point is that you want to think about what the CPU is required to do to feed the DAC. In general, a DAC that is capable of variable...</blockquote></div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">... CODEC without each signal interfering with the other. But that's an example of way too many bits in each word and way too many data transfers per conversion to be an effici!<br>
ent model. Your CPU will run out of power an order of magnitude faster with this approach.<br>
</blockquote></div></div></div></blockquote></div><br></div></blockquote></div></div></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></body></html>