Cool! Looks to be a good, 3kLOC or so? No small feat!
There are some oddities:
- There's no pan or zoom? Nothing immediately discoverable at least (right or middle drag, SHIFT, button).
- Weird that signal generators have inputs; I see these are actually gated or triggered parts. This is unfamiliar, but probably just a symptom of being an early version; standard SPICE and other logic parts can be finished later.
- Are labels supposed to be connectable? (Click on a label twice, it's acting as an output I think?)
- Are multiple outputs supposed to be connectable to a single input?
- No binary indicator outputs. Kind of unnecessary with the R/G output bubbles I suppose, but helps with organization?
- Hah, recursion check for feedback networks, nice. I take it, you don't have a solution for this, so it just prohibits it entirely? (I wonder how reliable the check is, can it be tricked..?)
This isn't so accidental, as XSPICE doesn't even behave right, most of the time IIRC. It's event driven, with gate delays implemented by strict delays creating a new event and so on; so, you can't make stable flip-flops from gates.
- Which, I wonder what you're doing here -- I guess given the real-time simulation scale, there isn't much point in simulating propagation delays; but then what, is it implicit just, propagating values along until a stable solution is found (and if not, error), or is it actually event driven? If event driven, this could be very powerful indeed, and, I might suggest looking into XSPICE, since it's free and open? -- though I don't have a clue how accessible its code base is, in terms of complexity, and tightness of integration with the SPICE core.
- The menus are very basic, I take it, manually implemented like everything else? A delayed mouseover following root (or submenu if applicable) would be nice, again something that can be added on.
- Also I can right-click the menus, which doesn't seem relevant
-Ahh I keep clicking away, hitting something on my bookmark bar -- an "are you sure you want to leave?" dialog, or something to remember previous state (local storage / cookie? something about form state, I don't know how browsers remember fields between forward/back??) might be nice.
- It bothers me that parts don't snap to the grid in any obvious way. Center? Coordinate reference, typically a corner of the bounding box or something? Pins? Pins rarely line up, at least.
- The double ellipse connecting lines are... uncouth to say the least, I guess; but honestly they're not a bad solution, considering the more proper alternative is some horrible rectilinear pathing algorithm, which also needs to run real-time while dragging a part(!) and inevitably finds the most awful paths anyway (Multisim, I'm looking at you). They do bunch up when a number of routes are nearly parallel, which doesn't look great. The colors could maybe be randomized to give better contrast.
- Oh yeah, speaking of red and green -- fine just for testing but don't make a habit of it, make them dissimilar intensity too! Red-green ambiguity is incredibly common (err, 5 or 10% of men?), and we color-sighted folk so easily forget this!
A number of these also highlight things I need to consider for my own long term simulator project, https://www.seventransistorlabs.com/Calc/Filter1~.html , which is also very poorly documented... 
Tim
Pan: hold ctrl while left click dragging, this will improve, no zoom yet, but I do plan to bring it in
Signal generators can be enable / disabled, that is why they have an input, at first they where enabled by default but a changeup in how logic high / lows propagate basically made is so it MUST have a high input to be considered high.
No labels shouldn't be connectable, there is a known bug that it will detect an output if you click on one would be if it had one to make a link, I need to fix that.
I assume that you are saying you connected multiple outputs from one device to to a single input of another? there is no explicit prevention of doing so, only explicit prevention is one parts output back to its own input, which can be overcome using a buffer (not a an electrical style buffer, but a recursion prevention buffer realistically).
Which goes into recursion, yes there is a hard cut (1000 recursions), before it stops it from looping, which is why there is a buffer part, it breaks the event chain via the shortest possible timer you can have in JS (most browsers that will be 4ms), before propagating the signal.
I am not trying to go for true electrical simulation, just proper logic simulation. I wanted something that is a little bit more capable then your typical educational logic sim, ultimately I guess it still falls into the 'educational' category, but I just want to experiment with logic designs in a way I can visualize, for example I could build the same things in verilog a lot easier ultimately but thats just a programming language, and sure I can make a fancy interface to interface to it to interact with simulated design in verilog, it's not quite the same as a graphical toggle switch or some such. My PRIMARY purpose is ultimately to design and build CPU's and run them virtually basically.
It IS an event driven system, so logic is completely detached from rendering, if say, you flip a switch to HIGH from LOW, it will go out and tell everything its connected to HEY, go HIGH, and it will evaluate itself if it needs to change any outputs, and if so go ahead and recursively go along until either there is no more state change, or it his recursion limit. At first I had it JUST like this, but then I quickly realized I didn't want to have to many fancy bus element for multiple connections to a single point, so now each element will call its container that holds it, if ANYTHING ELSE is sending a high signal to that input before it goes from high to low, so in this case it will properly handle multiple inputs and act like an OR at the input basically. The draw loop just draws thats it.
Yes everything on this project is completely made from scratch including the menu. I am still quite early on in UI, but getting close to a point where its OK and usable, hence why I am finally reaching out on here to find beta testers basically
.
Persistence is coming! I am going to use the local storage mechanism for at least personal settings, design saves can get pretty large if fairly complex, so saving designs to local storage isn't really feasible (5mb max on some browsers), but I still plan to offer it anyway and will just let people know their storage use (I will lzh compress the json data), but I do soon plan to build in a server based storage mechanism including design sharing, etc.
As far as grid alignment, there is work to be done to improve it, but currently it is the absolute top left corner of the element (not always visible), if you select by clicking on an element it will have a transparent bg outline, you will see that aligns perfectly to the grid.
I agree connections could be improved, currently it is just 2 quadratic curves with the control points each centered on the x and y axis between each element (connection points), since connections are drawn every frame I don't want to get too complicated with them, but I am open to ideas on improvements
. But one thing that is there at least in the view menu is the ability to either have them drawn above, below, or not drawn at all.
As far as colors go, I plan to make that user configurable, both default on/off colors, as well as individual outputs will eventually be colorable via properties window that pops up.
Home
Help
Search
Login
Register
