QCoils

[Yogi B]

... JohnH here's me telling more (in hopefully the most appropriate sub-board)...

QCoils is a tool set written in Python that aims to help in the development and debugging of guitar wiring diagrams. In it's current (pre-alpha) state QCoils is a library to be imported and used within another Python script, meaning some knowledge of Python is necessary but thanks to it's simplicity and some possibly questionable use of Python's flexibility, the learning curve should be minimal.

Here is a basic example of how to input the standard Strat wiring:

from qcoils.main.nets import NetList 
from qcoils.main.pickups import SingleCoil, SingleCoilRWRP 
from qcoils.main.switches import StratSwitch 

neck = SingleCoil('Neck') 
middle = SingleCoilRWRP('Middle') 
bridge = SingleCoil('Bridge') 

switch = StratSwitch('5-Way') 

n = NetList( 
    neck('Neck+', NetList.GND), 
    middle('Middle+', NetList.GND), 
    bridge('Bridge+', NetList.GND), 

    switch( 
        NetList.HOT, 'Bridge+', 'Middle+', 'Neck+', 
        None, None, None, None,  # tone control switching not relevant (yet?)
    ),
) 

n.print_truth_table()

Of particular note is the line of four Nones, this indicates that those terminals are left unconnected, as at the moment we are not considering the effects of tone controls, so we can ignore that half of the switch.

The n.print_truth_table() method outputs a truth table by sweeping the positions of any given switches, or when called with no parameters, all switches within the netlist, since in this case we have only the one it just sweeps the positions of our StratSwitch switch to produce the following table:

┌──────────┬─────────────────┬──────────┐
│ Switches │ Output          │ Warnings │
├──────────┤                 │          │
│ 5-Way    │                 │          │
├──────────┼─────────────────┼──────────┤
│ 1        │ Bridge          │          │
├──────────┼─────────────────┼──────────┤
│ 2        │ Bridge | Middle │          │
├──────────┼─────────────────┼──────────┤
│ 3        │ Middle          │          │
├──────────┼─────────────────┼──────────┤
│ 4        │ Middle | Neck   │          │
├──────────┼─────────────────┼──────────┤
│ 5        │ Neck            │          │
└──────────┴─────────────────┴──────────┘

Bingo, though what's this "Warnings" column? It's there to inform you of the the presence (or lack) of three potential issues with the wiring scheme: pickup(s) hanging from hot, shorted pickups, and an open circuit. Since we're covering the basics here with the standard Strat wiring, there's no warnings and we're good to go!

There is also the option produce a visual representation of the netlist in any given switching, via Graphviz, with a handful of style options. I haven't yet decided the best way to specify that you want this output produced, but here is an example output of the above position 1:



Future Plans / Possibilities

1. Finalize the current programming interface and output formatting.
   
   
2. Improve code quality and test coverage to a standard where I'm happy to inflict my code on others.
   
   
3. Include some amount of frequency analysis and graphing to give an impression of the audible difference between pickup configurations.
   
   
4. Write a GUI program that let's you input wiring diagrams visually.
   
   
5. Performance improvements either: from handing computationally heavy parts over to C via Cython or a C-extension; or by complete re-implementation in another language.
   

Background

QCoils was originally born out of my curiosity of implementing a system that reflects combinations of guitar pickups in two major aspects:

1. the ordering of parallel or series subgroups is arbitrary, i.e. P | Q and Q | P are equivalent.
   
   
2. total phase inversion has essentially no effect, yet differences in phase between pickups are important, in other words P | Q and ~P | ~Q are equivalent, but P | ~Q and P | Q are not.
   

Once I had that system set up correctly, I realised that if I were to iterate over every possible permutation of a certain number of pickups, every way to group them in series and parallel, and (optionally) every way to phase them -- then eliminated duplicates as determined by the two rules above, I'd be left with a list of every unique series-parallel combination of those pickups. This is obviously a brute force, thus inefficient method to achieve this, and I have since figured out a better algorithm to create this list, however this method still has it's uses when it comes to testing.

Next (and as a bit of an aside) I wondered about restricting such a list to the combinations that, assuming all coils were identical, would be hum-cancelling. This is where the opportunity for adding in frequency analysis comes in as the way I'm currently achieving this is by creating the previous list, then 'manually' calculating the output voltage of each combination which ain't exactly the fastest thing in the world. This has also become a bit of a sticking point, in that both an algorithm to generate the unique humbucking combinations efficiently and a mathematical function for calculating the number of such combinations, have so fare eluded me. This has had an upside though, as it lead me to want to visualise the pickup combinations in order help me try to spot the pattern behind what makes a combination humbucking.

The major turning point came through thinking about comparing pickup combinations, I realised that what I had developed could be used to check a calculated coil combination against a user specified one, thus I had the basis of something that could check an unknown wiring diagram against it's intended function.

[JohnH]

Hey Yogi - that sounds like a major piece of careful thinking and coding - congrats on the progress so far. It seems like a great tool!

Finding hum cancelling or at least hum reduced combos is a trick, but I reckon you could do it, stating with a basis of all equal coils. The trick is that there are some three-coil combos that are fully humcancelling, eg, two in-series, all in parallel with one with reverse hum is hum cancelling.

good luck with your development.

[newey]

Bravo, Yogi-

Your technical analysis is way beyond me but I see where this could be really useful.

[Yogi B]

This is just an update to say I have still been working on this, though not immediately recently.

The first post could do with an update as since then this has gone though a pretty big overhaul. I've rewritten most of how components and the connections between them are defined, as well as moving the connection information to the directly to the NetList object, rather than being spread about the place.

I've also squashed some issues I was having when trying to convert that information to a series/parallel network.

Plus that made me realise that there's ambiguity in some cases, which as far as I can determine is unavoidable. For instance imagine you have the configuration which would normally be (A + B) x C x D, but at some point the (A + B) x C sub-group is shorted. Ideally I'd like to warn exactly that, "sub-group (A + B) x C is shorted", but as far as the program is concerned there are just three edges between two nodes. Thus instead of it being the aforementioned subgroup being shorted by one those nodes, it could easily have been the subgroup A + B + ~C hanging from that node.