New FV-1 based effect

[MarkusBass]

There is a new programmable effect based on FV-1. It has full MIDI support and a nice enclosure. Etap2hw is one of possible ways to use it.
More details are available at: http://eagle-audio.eu/

Mark

[Ice-9]

Congrats on a Fantastic looking FV-1 rack, love it.   

[Digital Larry]

Looks cool.  I'll tell you what springs to my mind, which is probably completely impractical, but that's just the way I roll!

Looks like you have to program the FV-1 separately, rather than using the LCD on your box.  Well that gets pretty difficult!  But how "could" it be done?

When I first started writing the application now known as SpinCAD Designer (TANKASD for short), it had no UI and I just wrote Java code on top of ElmGen that would link functional blocks together.  ElmGen has utilities that TANKASD doesn't use currently, to generate hex files that you could load into the EEPROM.

Assuming that you could somehow get a Java Virtual Machine (JVM) running on your embedded processor (which is probably ridiculous), you could create a set of master "structures" much as you have with a programmable effects box like a Boss VF-1.  You call up one of those structures (i.e. a TANKASD patch) and start editing the parameters on the LCD (i.e the TANKASD Control Panels).  Unfortunately every parameter tweak would necessitate writing to the EEPROM.  You still couldn't get the level of flexibility of crazy patches that you could write by hand or using TANKASD.  

The amount of code space required for this is the big question, and possibly the performance of a small controller trying to run a JVM - it's most likely quite inefficient.  Is there a better way?  Probably, but you'd need to develop the whole thing from scratch.

[eagleaudio]

This would require a much stronger processor and probably FV-1 also should be replaced in this case. Of course I have to write programs separately (and upload them to the effect via USB interface). Each program has a set of predefined parameters than can be modified within certain limits. New values of the parameters are hold in the memory of the processor. They are saved to EEPROM only when the effect is switched off.

eagleaudio

[Digital Larry]

Don't get me wrong, I think your work is great.  If we "throw out the FV-1" then my work becomes unimportant, so I'm not ready for that!

Let's think about a different approach than trying to leverage ElmGen to generate hex code on the fly.  A master patch represents a Spin ASM program (assembled to hex in this case).  Adjusting certain parameters within this program amounts to changing certain things (constants) within that program.  It could even be done at the hex level if you spent the time and pain to understand which bits to edit.  (btw, it's always fine for me to dream up major things for other people to do).   

Another thing I thought about was the general need to expand the available programs beyond 8 external.  I tried to find some implementation on any microprocessor where some I/O pins on the processor masquerade as an EEPROM from the FV-1's perspective.  Didn't find anything concrete so far.  While the system was in editing mode you could be serving the FV-1 info out of RAM, to avoid issues associated with excessive flash writes.  Once you WRITE a given patch then yes it gets stored to flash.

My issue is that SpinCAD Designer's flexibility and speed have resulted in (at least) dozens of different patch types that I'd like to explore, so for a standalone box with an LCD I want to try to split the difference between a full editing environment as on the PC and just having 8 patches at a time, there you go.

[Ice-9]

Just to throw my 2 pence worth in. What would be a great addition to programming the FV-1 would be TonePrint type of environment , but I think this would be a huge amount of development to get close to this type of editing for the FV-1. (wishful thinking).

@Digital Larry, I know your SpinCAD Designer sits somewhere in the middle. Adding a usb interface to the FV-1 circuit as eagle -audio have done is a good step to connect directly to the PC/Mac and allow SpinCAD to send hex files to the Eeprom. (I'm assuming SpinCAd already has the ability to send hex to the Eeprom).

[Digital Larry]

@Digital Larry, I know your SpinCAD Designer sits somewhere in the middle. Adding a usb interface to the FV-1 circuit as eagle -audio have done is a good step to connect directly to the PC/Mac and allow SpinCAD to send hex files to the Eeprom. (I'm assuming SpinCAd already has the ability to send hex to the Eeprom).

Hi Mick,

Up to now I have depended on the Spin IDE for hex code generation and programming of the demo board.  SpinCAD spits out Spin ASM for this purpose.

Apparently the ElmGen library also supports hex code generation and it would be easy enough to add a menu item to try that out.  I don't however support programming any hardware directly from within SpinCAD Designer.  If enough people thought that was what really needed to happen then I'd look into it. 

The poll I put up at my forum so far indicates people (who responded) mostly want more blocks, and my personal feeling is that I need to spend time refining the blocks I already have because I slapped a lot of them together back when my understanding of the FV-1 was not quite where it is today.  I also have a backlog of usability issues and annoying bugs, which unfortunately aren't as much fun to fix (cough).

DL

[Digital Larry]

Mark, what's in a "user patch"?

[eagleaudio]

User Patch contains parameters settings for any of 8 External programs. So you can switch to e.g. E01 external program, change its parameters and save those changed parameters as e.g. U05 patch. Then, when you select again U05 patch (even when you switch the effect off and on) it contains E01 program with modified parameters. It means that you may consider patch as a favorite seeting of a given external program. You can also dump User Patches as SysEx MIDI messages (and save it for latter use).

Eagleaudio

[eagleaudio]

Another thing I thought about was the general need to expand the available programs beyond 8 external.  I tried to find some implementation on any microprocessor where some I/O pins on the processor masquerade as an EEPROM from the FV-1's perspective.  Didn't find anything concrete so far.

As you know FV-1 supports up to 8 external banks. In fact, this comes from the fact that FV-1 can address up to 4kB external memory and it uses hardcoded I2C interface address. But there are many ways to extend the number of external effects. First, you can connect up to 8 external memories to the FV-1 and set the default 0x00 address for the only one at a time. This makes you able to support 64 external banks. It is the simplest way but there are more other ways to obtain as much banks as you need. Our DSPfactory device is equipped with special PC application that makes you able to change external banks including they names, settings etc. You can save and load 32 patches as well doing that by MIDI interface...

Eagleaudio

[slacker]

Looks very nice, the ability to save patches is a great idea. If you don't mind me asking, why have you used so much filtering particularly before the FV-1? I've built a few different things using it and never found the need for any pre filtering beyond the RC filter in the data sheet.

I tried to find some implementation on any microprocessor where some I/O pins on the processor masquerade as an EEPROM from the FV-1's perspective.  Didn't find anything concrete so far. 

You should be able to do this with any micro that has an i2c port and enough flash memory to store the data from however many a Spin hex files you want, I haven't seen any specific examples either though. I've got some suitable PICs to hand so I'll have a go at it, looks fairly straightforward, the FV-1 does a sequential read to get the data from the EEPROM, the procedure for this is laid out in the 24LC32 data sheet so you just need to make the micro give the correct responses and then spit out the data.
The harder part will probably be coming up with a nice way to get the data out of a Spin hex file and into the micro, I got as far as writing something that sent a spin hex file to a PIC via serial, the PIC then stripped the data out of the hex file and wrote it to the EEPROM. A similar approach might work for this.

[free electron]

You can output the FV-1 program as a c header file directly from the SpinAsm. Just check the "SourceFile" in the compile/build window. It's generated as an array which you can include in your program.

[slacker]

Thanks for that, in all the time I've used SpinASM I'd never realised you could do that, that's brilliant.

[Digital Larry]

You should be able to do this with any micro that has an i2c port and enough flash memory to store the data from however many a Spin hex files you want, I haven't seen any specific examples either though. I've got some suitable PICs to hand so I'll have a go at it, looks fairly straightforward, the FV-1 does a sequential read to get the data from the EEPROM, the procedure for this is laid out in the 24LC32 data sheet so you just need to make the micro give the correct responses and then spit out the data.

That sounds promising!  I'm not into bit banging much these days, having been diverted over to the somewhat head scratching world of Java Swing application development.  Let me know if you come up with something, as I think that is truly the missing link to creating a powerful micro based FV-1 circuit.

[eagleaudio]

If you don't mind me asking, why have you used so much filtering particularly before the FV-1? I've built a few different things using it and never found the need for any pre filtering beyond the RC filter in the data sheet.

I've seen several effects based on FV-1 and they were noisy. I wanted to avoid this. It is possible that there were some othere design problems but I thought that it's better to have very good filters than a noisy effect.

Eagleaudio