Searching an intelligent 4 input selector box

[PRR]

Parallax BASIC Stamp is a teeny controller for NON-programmers. Yes you have to tell it what to do. No, it isn't traditional programming, more like a "How To" for cooking or stage setup.

OTOH, if you can figure how your switched jack can tickle the CLK input of the 4017 when it hits an unused hole, it may be simple hardware. (I can see it but only with much more complicated jacks than we use.)

[ElectricDruid]

So, looking at the ElectricDruid's schematic, there's just some changes. I kept the input caps 1uF and the 10uF output, to avoid any low end cut. I reduced even R4 560R to 100R, for a little bit more transparent signal.

The resistor in line with the output is to help the op-amp maintain stability when there's a decent amount of cable (and therefore capacitance) plugged into the output. Reducing it reduces that margin, but unless you plug a long cable in, you'll *probably* never notice.

I guess all these changes make a tiny difference.

They do. The original way was done that way for a reason.

Another change is about the biasing of the TL071, not for my choice, but due to the layout design. Two 2.2M resistors on the 9v and on the ground. I think that is ok (or even better?).

It's almost certainly not better. Think about what happens to power supply noise with the new way - exactly half of it is coupled directly into that input. The other way with the voltage divider includes a capacitor that filters this power supply noise and provides a low impedance path to ground. Here's a reference:

https://www.analog.com/en/resources/app-notes/an-581.html

Will it work with the 2M2s? Yes, it'll work. But in my view these changes are not really "improvements", sorry. I understand the need to get things to work on a stripboard layout, and I know from experience that that isn't easy, so perhaps a few compromises have to be accepted. You choose how many - it's your project.

HTH

[R.G.]

Only mildly more complicated is Great Cow Basic ("GCB"). It's a true compiler, and accepts more-or-less standard Basic syntax.

I mostly quit using anything else for PICs because its just so fast and easy. I once programmed an eight loop programmable any-order FX switcher in GCB. For stuff like sensing foot switches, it's plenty fast enough.

The programming for this function is incredibly simple for everything except switch debouncing. Mostly, if you can write down how you want the footswitches to act, in English, the Basic code just falls out - with one exception, that being switch debouncing. I used a variant of a vertical adder routine to sense up to eight inputs simultaneously, then debounce them all simultaneously, but independently.

If I was writing this app, I'd pick a 14 pin PIC, like perhaps the 16F15323, about US$1.50 in one. Then:

====
' initialize a bunch of PIC specific stuff; this is chip dependent
' initialize a bunch of variables used in the program; here is where any memory of previous state would be raised from the dead
' set up a 10mS interrupt on a timer, so that the program has to sample footswitches every 10mS

MAIN:
IF footswitch_state was changed by the switch debouncing THEN change the actual output pins, move the previous state to a variable so we can tell it changed

GOTO Main:

ON_INTERRUPT:
' 10mS tick happened
' read the input pins
' use input pins' state this interrupt to compute any changes
' IF any switch was debounced to a new state, write it into the variable that MAIN checks for changes
' update previous states so we can tell something changes from now
RETURN

[PRR]

> Great Cow Basic

Good stuff if you know what a PIC is. The STAMP series pre-solves many detail that confuse beginners (even me, when not working on PC class machinery). You pay more for board and cord but it is plug and play. To each her own, of course.

[PRR]

> ....It's a true compiler, and accepts more-or-less standard Basic syntax.

For jobs like my blower-control, and Elijah-Baley's switch-fitting, most BASIC syntax is over-kill, and thus frustrating to the first-timer. GOTO is NOT "harmful" if you only have a dozen lines and don't have experience in thinking IF..THEN..ELSE. Compiled or interpreted is purely an implementation detail which should not be left to the ignorant.

Liam posted a deep-thought piece:
https://www.theregister.com/2025/01/03/reevaluating_basics_legacy/
I don't agree with half his thesis-- he may not have gone far enuff. And today I don't care which company to blame for BASIC's supposed downfall. But there is food for thought.

(Yes, I think FORTRAN 58 is, after machine-code, the one true language; why do you ask?)

[FiveseveN]

While we're still on the subject, there are "visual programming" platforms for Arduino (and others) that let you bypass the coding entirely:
https://xod.io/
https://www.visuino.com/
http://www.visualino.net/
https://mblock.cc/
https://github.com/BlocklyDuino/BlocklyDuino-v2

[R.G.]

Good stuff if you know what a PIC is. The STAMP series pre-solves many detail that confuse beginners (even me, when not working on PC class machinery). You pay more for board and cord but it is plug and play. To each her own, of course.

I had not looked at the BASIC Stamp for a long time. The real ones are expensive ($13 to $29) but the clones are down at about $6. The Arduino Nano is about the same, with clones down at about $5 or so. Arduino stuff generally needs programming in what amounts to C++, but much of this is hidden inside the Arduino IDE.

Over the years, I've become language agnostic. I write down what I want to do in kind-of-English statements that mimic the programming statements I'm used to, like GOTO, GOSUB, IF-THEN-ELSE and so on, and then get out the specific language manual and start transcoding.

The joy, and at the same time curse, of BASIC to me is its simplicity. Need a new variable? Just type in a new variable name and assign a value. The curse of that is that it allows you to subtly hose up something you did elsewhere in the program.

A whole lot of the "advances" in newer languages is designed to force the programmer to not make subtle mistakes by making the compiler refuse to play along. Declaring variables and types is actually good programming hygene, even if it's infuriating. I cursed at Arduino/C++ scope declarations a lot, but finally figured out that this was freeing in many ways.

If you even want to have fun reading about computer languages, look up the "Whitespace" language, which has all of the language syntax in non-printing characters. 

[ElectricDruid]

A whole lot of the "advances" in newer languages is designed to force the programmer to not make subtle mistakes by making the compiler refuse to play along. Declaring variables and types is actually good programming hygene, even if it's infuriating. I cursed at Arduino/C++ scope declarations a lot, but finally figured out that this was freeing in many ways.

I agree, but I've still never been able to get on with C's "header" files. That just seems like it's *you* doing work for the compiler's benefit. Like "I'll tell you what I'm going to do, so you don't have to work it out". It's a damn computer! Working stuff out is what it's *for*!! Do another pass of the code if you want to see what variables and functions I've declared. Grrr. Other languages don't seem to need this "ahead of time" declaration of every bleedin' thing, so it's not "necessary" in that sense. Bugs the hell out of me. Plus you finish up having to do a load more pointless statements so as not to include the same header files multiple times if several files in your project all need the same stuff. It's really the worst way to try and "organise" things. Dozens of files, all with another file that says what's in them, and then a ton of dependencies between them all. Nightmare.

Ok, sorry...please feel free to get back on topic and I'll shut up!!