[sdiy] Digital Synth Module ideas ...

[Seb Francis]

>> although probably it would be quite good with raw waveforms.
>>     
>
> Yes. Let's put it through an LPF and a VCA and see what happens.
> An unfiltered, static saw tooth wave doesn't exactly sound
> appealing either.
>
>   

Yeah, very true ... filtering will definite make these chopped up 
waveforms more appealing.

>>> For a hardware implementation of bit swap, I would use an ADC and
>>> a DAC back-to-back with a patch panel between the two, say 12 jack
>>> sockets for the top 6 bits. It's intuitive and it opens the
>>> possibility of doing bit-bashing with external logic modules like
>>> the CGS26 and CGS39. IMO that would be a better interface than
>>> anything you might achieve with a micro-controller and a bunch of
>>> buttons and LEDs.
>>>       
>> Interesting idea :)
>>     
>
> Not knowing how much sarcasm there is in this reply, <g>
>   

No sarcasm intended :)

> For bit swapping, you could use CV inputs 1 and 2 for bit number
> selection. Sounds a bit fiddly to me but so do analogue sequencers
> and yet people swear by them.
>
>   

I don't think I'd use the CVs like this.  I prefer to have CVs causing a 
smoothly changing effect, otherwise it's just a bit of a waste of a CV 
input and you may as well have one or more buttons with LEDs (or gate 
inputs).

I'd probably take a nice sounding bit swap as a starting point (e.g. 
bits 13&14) and figure out a way to mathematically morph from 
undistorted to fully bit swapped.  Then control this with a CV.

>
> The assumption that it's quicker to do DSP in a general purpose
> scripting language than in a general purpose compiled language
> merits examination, Mr. Francis. Compare C and Perl, for example :
>   

Well perhaps I'm just lazy and don't want to master yet another 
programming language and associated libraries ;)
.. and I do like to be able to just edit and run without compiling every 
time, then opening a debugger when the exe core dumps on me!

>   #include <stdio.h>
>   #include <stdlib.h>
>   int main () {
>     short v;
>     while (fread (&v, sizeof v, 1, stdin) != 0) {
>       v = abs (v);
>       fwrite (&v, sizeof v, 1, stdout);
>     }
>   }
>
> vs.
>
>   #!/usr/bin/perl -w
>   use strict;
>   my $buf;
>   while (read (STDIN, $buf, 2)) {
>     my $v = unpack ('s', $buf);
>     $v = abs ($v);
>     $buf = pack ('s', $v);
>     print $buf;
>   }
>
> Is one less "fussy" than the other ? And TCL is not likely to fare
> particularly better than Perl, since it treats arithmetic
> expressions like second-class citizens...
>
>   

It seems that all 3 languages are pretty similar for this little example ...
(although TCL will look the weirdest to people familiar with C syntax!)

#!/bin/tclsh
while {[string length [set word [read stdin 2]]] == 2} {
    binary scan $word s1 val
    set val [expr {abs($val)}]
    puts -nonewline [binary format s $val]
}

Both scripting languages are a bit ugly when it comes to getting packed 
16 bit integers from a file/stdin.  But once those 2 lines are written 
then the maths operations can be carried out just as easily in any 
language.  TCL handles maths operations just fine as long as you are 
aware how it handles auto-converting between variable types.

Seb