More fixes!

• 74HC245 fixed issue with the DIR pin not functioning correctly and causing a crash due to matrix error
  
• Corrected pin labels for 74HC245 and 74HC273
  
• Fix issue with a single remaining pin label after a component delete with pin hints enabled

All the best

Mike

I have removed support for AVX2 for the time being as it would appear that some users do not have support from their CPUs.

The performance loss is negligible, if any, and should stop crashing for affected users!

As always, please get in touch with any issues that you may be having

All the best

Mike

In the last 24 hours since 1.3 was released, a couple of errors have been noted. I have worked hard with several users to isolate the problems. I honestly cannot thank them enough for their patience.

I have updated a few key areas, which should significantly improve stability and hopefully stop some users getting crashes when placing unconnected components and creating wire loops with switches. Circuit Math is very complex and I am always improving the detection of singular matrices or convergence issues

I had managed to miss out a critical multiplication when optimising the Transistor, which was causing convergence issues for the simulation!

All the best

Mike

Simulation speed was always the limiting factor for the future of CRUMB. No matter how much work I put into other areas, I was always hit with the same issue and I was not able to achieve the vision that I wanted for CRUMB.

Initially I had said that I had found a 2000% increase in performance with last month's development update, but that milestone has since been blown away and CRUMB is now something in the region of 20,000%+ faster 😏

I'm not going to go into every last detail of how this speed has been achieved, but for all of you that are technically minded, here is a short summary of how this feat was achieved:

• Replacing my linear matrix algebra with a high performance KLU-type algorithm
  
• Pre-processing all unknown variables to reduce runtime overhead of matrix operations
  
• Pre-processing allows the Symbolic Matrix to be calculated once
  
• Pre-processing allows the circuit matrix to be "refactored" on every timestep, not full factorization
  
• Extensive use of unsafe code in C# to allow low-level memory integration with external C++ used for the circuit Matrix
  
• Pre-processing all pointers for memory manipulation to allow lighting fast matrix operations

As previously mentioned, this increase in performance means that it is now possible to build and run large circuits, including my recreation of the Ben Eater 8-bit CPU. Ben's fantastic series[eater.net] on building an 8-bit CPU led me to create CRUMB with the dream of users being able to build the design themselves. And now it is possible.

Before you download my example and watch the video below, I highly recommend you have a go at building your own CPU! I found it to be a hugely rewarding experience being able to build, test and debug my own attempts 🤗 it took me about 3 weeks from building the clock module, to running a simple program.

Here is the link to my 8-bit CPU Design which is ready to be programmed
8-bit CPU Download[drive.google.com]

For instructions on how to program the CPU and run instructions, watch the video below where I give a guide on how to use the Arduino to write the Microcode to the EEPROMS and also how to program the RAM manually to run a simple program 😊

With these changes above it is now possible for you to run some circuits at 96,000Hz! And currently that is just a limit I have chosen for now until I can get an idea of how circuit complexity correlates with the simulation speed

Changes to simulation settings menu - Simulation speeds of up to 96,000Hz. Timestep slider removed and replaced with a realtime speed adjustment


Alongside the main work of this update, I have managed to include a few other bug fixes and changes that should help towards stability of the program. I'm not going to be able to list out every fix but some that are included:

• Recognition and handling of Matrix errors. Mathematically discrepancies are checked for and will alter the solving system to re-evaluate
  
• All component models checked and verified for floating lead connection errors. There have been some peculiar circumstances where placing a disconnected switch in a circuit was causing errors
  
• Re-work of the audio system to deal with the new circuit frequency levels. Buffer under-run handling (basis for audio update incoming)
  
• Minor procedural fixes with editing, loading and saving causing lags in performance due to unnecessary recalculating
  
• Arduino interpreter procedure altered to synchronise with the new circuit speeds. Performance increased
  
• Plus many more minor additions/fixes

Hello everyone, just a quick update on progress!

I am for the most part complete with the speed update, it is actually now possible to run some of the circuits at 96,000Hz which is great news... especially if you want to create circuits for audio/analog processing 😍

However, I am going through a few checks and tidy ups with everything to do with audio input as I want to compile two updates in to one, as I feel like everyone has waited for long enough for an update!

I am still aiming to be finished within the next week or two, please just bear with me 😊

Work on the first major update is going well, although I am up until 2-3am most nights working away hard!

Speed is the major update to begin with, it has got to the point now that it is actually immeasurable just how fast I have managed to get the simulation running. Some circuits I have had running at nearly 200,000Hz!!

Even the Ben Eater 8 bit CPU I can run at 2,000Hz with ease on my 2019 MacBook Pro!

With this new found speed, the door has now opened up for Audio and analog signal processing. My work is going to be cut out making the oscilloscope better!

I'm getting very very excited, here are a couple of videos from my development version which is using the latest update features. First video shows a simple Guitar Overdrive circuit which is running in real-time on a Wav file...

And then of course, my own build of the Ben Eater 8bit CPU (which was the reason I started making CRUMB in the first place :D)

Will keep in touch, still aiming for early November for the update cycle to begin!

Cheers, Mike

Some of you will have already seen in the discussions that I have been made a major breakthrough in the development of CRUMB. Since before I even released CRUMB nearly 2 years ago, I have been constantly searching for more performance and speed.

As a developer, I have been completely blown away by this new performance.

I will give a full breakdown of changes when I release the update, which should hopefully be at the start of November. I have been working through many of the niggles and bugs that have been mentioned, whilst also extracting every possible piece of performance from the new system I have implemented.

To keep you on the edge of your seats, here is the Ben Eater 8-bit CPU (https://eater.net/8bit) that I have been able to build and run at over 600Hz on my 2019 MacBook Pro! Bring on November...

Just a quick update to show that I am pouring long hours in to making CRUMB Advanced as detailed and complex as possible 😄. Further developments include:

Dockable Panels and Windows
Hierarchy Browser
Transform Tools
Material Editor
+ much more!

Below is a quick screen recording of the latest iteration of the component editor UI

Cheers!

Mike

The core concept of CRUMB 2.0 is to be able to give the user the ability to create any component, mechanical or electrical.

The starting point is the importing of a 3D representation of that component. Switching to the Unity UIToolkit, I have been able to create new runtime tools to allow the user to import a variety of 3D model formats and offer material customisation.

Below is video from the conceptual build testing the new modelling/material tools