does spinCad limit memory at all ?

[Boner]

Been messing around with spinCad and was wondering if, for any reason, it greatly limits the amount of instructions you can use in a program or the amount of delay memory you can utilize

I know you can make things more efficient with writing code manually, but other than that does spinCad impose any larger limitations in regards to memory?


Also, is it possible to have 1 large program instead of 8 smaller ones?

Thanks all!!!

[Digital Larry]

Thanks for the question.  SpinCAD's inefficiency mostly boils down to this:

Each block allocates a register to hold its output value.  It also uses an instruction to write that value into the register in the first place.  And then the downstream block uses an instruction to read that register.  So the only inefficiency this generates is in registers and instructions.  The more blocks that get daisy chained together, the more these get used up.  That said, it is easy to spot those places in the generated code and hand optimize them. 

There is no wastage of delay RAM at all.  I've been doing some recent experiments into things I hadn't tried in a long time and there are a few things that don't work well, such as pot skipping code.  It works, but when you add in some of the macros (such as detecting whether a pin on a given block is connected, so you know whether or not to generate any code for it) the jump lengths are not being calculated correctly.

As far as the "1 large vs. 8 small" this is imposed by the FV-1 itself, not SpinCAD.  I'd LOVE to have ONE BIG patch.  OMG those years of therapy down the drain, I thought I'd put that all behind me.

You can learn way more than you ever wanted about SpinCAD over at... drum roll... https://www.patreon.com/holycityaudio.  I have an article devoted to optimizing the generated SpinASM if you really have to do that.  You can accomplish a lot without ever having to.

In this week's session, we are pulling apart the "Minimum Reverb" block to understand what the all-pass coefficient does in the input chain and in the reverb loop.  What are the best lengths for those all-pass chains?  Until I started diving in I considered all of those "magic numbers".  But now I think I have a much better handle on it.  The great thing about SpinCAD compared to working with FV-1 assembler and the chip itself is the speed at which you can change things and audition them in the simulator.

I could go on... (and do)...

DL

[Cybercow]

From what I know of SpinCAD and the FV-1, SpindCAD uses building blocks that get transposed to a format required to populate the space in an EEPROM. The FV-1 is limited to 128 code-lines per "patch". The FV-1 can read from up to only 8 different patches at a time for a given "bank". All 8 patches of a single "bank" cannot be rolled up into one large "patch" because of the 128 code-line limit per patch.

Part of the challenge with SpinCAD, to squeeze more out of the FV-1, Digital Larry has posted some suggestions (on his Git-Hub site: https://github.com/HolyCityAudio/SpinCAD-Designer/blob/master/docs/optimizing-spin-asm-code-generation.pdf ) for optimization of the code with SpinASM.

I've save SpinCAD patches, (while the resource bars are red - indicating the patch will likely NOT load into the EEPROM when converted), saved them as SpinASM files, then followed Digital Larry's optimization techniques to try and get the code-lines down to ≤128

Sometimes, it works and sometimes it doesn't (I'm still struggling with SpinASM.)

As for the memory, if you're referring to the "Delay Ram used" resource bar, note that the FV-1 is limited to 1,000 ms of delay time by its specification. (See the datasheet.)

From my experience, SpinCAD imposes no limitations on that "Delay RAM". SpinCAD does tend duplicate some code lines and so contributes a bit of bloat with regard to the instruction resources. DL frequents this forum on occasion and may or may not reply further. He knows SpinCAD best.

I like futzing with SpinCAD. The real challenge for me is getting more comfortable with SpinASM. Digital Larry has rekindled his activities with SpinCAD Designer development and carries on some detailed discussions in subscription blog at https://www.patreon.com/home.

[Digital Larry]

Sometimes, it works and sometimes it doesn't (I'm still struggling with SpinASM.)

You're paid up this month.  You can ask a question!

Thx for the plug.

DL

[Cybercow]

Sometimes, it works and sometimes it doesn't (I'm still struggling with SpinASM.)

You're paid up this month.  You can ask a question!

Thx for the plug.

DL

LOL! Apparently, we were typing a response at the same time. You just type faster than me.

There will be many questions. I just need to get my build queue reduced to where I have the FV-1 patch creation/learning items listed. Three projects to go!

[Vivek]

My simple understanding and way to explain SpinCAD:

Most of us are not developers of DSP routines.

If we had to program the FV-1 using SpinASM, I suppose most would find existing code snippets from the factory patches etc, and use a text editor to paste that, and then manually "join the pipes" between the various effects and controls.

I feel in essence, that is what SpinCAD does, but using a graphic interface for ease of editing, and added goodies including monitoring the sound on the PC.

I feel that suppose a reverb code has maybe 80 steps, SpinCAD might roughly add 2-4 steps and 1-2 registers more to connect this code to what came before and what came after.

So in case your SpinCAD generated code fits on the FV-1, go for it !!

In case SpinCAD generated about 10 steps more than the limit of 128 instructions, one can look at manually editing and optimizing the generated ASM

But suppose SpinCAD generated 50 steps more than the 128 instruction limit, you need to seriously relook at what you are trying to achieve from one FV-1

On the other hand, SpinCAD does not impose an extra bloat on the delay memory at all. Both SpinASM and SpinCAD have access to exactly the same amount of delay memory.

Hope I understood and explained it correctly.