its doable but you would have to learn a bit more about the hardware on your own. the combination you describe is very similar to what we used to prototype.

there are different devkits. if you mean this one
http://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/bf537-ezlite.html#eb-overview

then that is pretty close, it has the same amount of SDRAM, but you will have to write your own code for audio I/O using AD1871 (ADC) and AD1854 (DAC) instead of AD1939 (codec.) SPI init code and slave boot should be pretty easy/similar. not sure about SDRAM and clock init code, but there are plenty of bf537 sample applications if you search for them. most are written for the VisualDSP compiler suite but blackfin.uclinux.org has tips for porting to the bfin-gcc toolchain. (in fact IIRC there is generally more sample code for bf537 than for bf533.)

hm, you would also be missing half the audio I/O channels and all the CV output. getting the audio daughterboard would solve that.

the avr32 side might actually be more difficult as there is more hardware-specific stuff for all the peripherals. you would have to build out the screen, encoders, CV input, serial I/O and probably other stuff - for example, i can’t remember if any of atmel’s devkits have that much SRAM, or if any have both a USB device and a host port.

application code (e.g. bees, prgrm) is actually quite portable, just doesn’t do much without the low-level stuff provided by aleph avr32_lib (timers, CV in, screen, usb drivers, filesystem, SPI drivers, etc)

so i dunno, maybe that sounds like a good time to you, maybe not! or maybe just focus on the DSP part and follow the (very simple) param change / boot sequence serial protocol, for aleph compatiblity. (this is another way of phrasing trent’s suggestion. i too like the STMF32 discovery board, although i’ve run into a surprising number of bugs in the the STM peripheral libraries. if you’re developing your own control application you could use any microcontroller powerful enough for your needs.)

EDIT oh, just clicked the link. that looks nice! cheap and minimal with easy access to pins. but the same caveat applies as far has having to source quite a few other parts to get a working controller section together. and you would definitely need to add SRAM and configure the driver for it, which i found to be relatively tricky. bonus of that board vs. an atmel devkit is that it looks relatively easy to have a totally arbitrary pin configuration (thus, you could closely match the aleph board), the downside is you have to add pretty much everything yourself. which would be expensive and time consuming but certainly educational.

2 Likes

Thanks for answering, great information.
so yes I have the bf537 EZLite that you link. in the beginning I won’t try to completely replicate the Aleph’ functionality. I was thinking more of building say a wavetable synth with effects: this would allow me to get the required experience to better understand the source code and the architecture of the Aleph. So the missing features, like CV and more limited audio I/O are not a problem for now.

Of course, it’s on the low level stuff that I will be slower. I checked the application code and I can follow it: drivers, screen, etc I don’t.

From the same vendor I have now found this one
http://www.alvidi.de/shop/product_info.php?info=p32_AVR32-Development-Board.html
That also looks quite promising: there are way more peripherals.

So now I have another question: I think I am set on one of these two. Shall I get the more complete one? There’s the option to have a AT45DB321D Data Flash installed, I guess I should go for it, no?

It would be so cool to have another practitioner working with me with the same setup: if anybody from the forum wants to join on, everything it’s going to be easier and nicer.

hm actually this other board i don’t think does a lot for you as far as approximating the aleph. it comes with SDRAM instead of SRAM, so the heap memory is much bigger and slower. RS232 port would still needs conversion to serial-usb (aleph uses a slaved AVR8 running LUFA for this; older monome devices used FTDI.) ethernet would go unused (unless networking is part of your vision.)

we don’t use any extra flash in the aleph beyond the internal 512k. (bees app stores everything on the sdcard - in hindsight more flash would probably have been a good idea; as it is we should at some point redo the scenes structuring to be more space-efficient and store the default scene+module internally.)

so my 2 cents would be: if you want to use avr32 go with the barebones version and build on it from there.

or maybe you have something else lying around that could serve as an initial testing controller. for example, an Arduino Uno would work fine - it has USB host capabilities and SPI, and is easy to program.

ok, well last night I was thinking wether it was ok to use Arduino Uno. so, cool, for now I’m sorted! Will start try to get SPI working already today

yeah i think that would be perfect - see if you can boot the bfin in SPI slave mode by sending .ldr file from the Uno, then send parameter changes once its booted.

pins used:

SPI

  • clock
  • select
  • MOSI
  • MISO

GPIO

That’s such great info. There’s a rotary switch on the EZ-KIT that determines the boot mode of the processor.
The loader file to blink a led on the dev kit is 15 Kb, before I can even send a .ldr with SPI I’ll need some sort of storage or file system on the Arduino Uno (I had thought to save it as a literal char[] at least for a first try).
So now I am checking out flash.c and so on, as soon as I have something working I’ll write a follow up, maybe someone is interested.

oh dear, i’m very sorry but i was totally thinking of the Due when i made those statements
https://www.arduino.cc/en/Main/arduinoBoardDue

that is the much bigger and faster ARM-based board with 512K of flash and USB host capabilites. it is actually more capable than the uc3a0512 and easier to work with. we even made an official monome host library [ https://github.com/monome/MonomeHost ], so it can talk to serialosc devices.

the Uno only has 32k of flash, runs at half the clock speed of the uc3a0512, and provides minimal I/O. blackfin executables can be up to 64K (and it’s not hard to hit that if you are using, say, static wavetables). so the Uno (sans external storage) will only work for the most basic test application. which could still be fine for starters.

heh, yeah I think I can make it with the UNO, but that means keeping both bfin and SD card on the same SPI… and, I’ll need to read the “ldf” files from the SD in chunks, select the blackfin, send the data, select the sd card, all this in a loop because the memory is too small to keep the whole file. I will move to the Due after the holidays, even though dealing with Uno’s limitations has been quite instructional today.

curious if you had any success with [quote=“alesaccoia, post:6, topic:818”]
building say a wavetable synth with effects
[/quote]
on the bf537 EZLite kit ?
@alesaccoia

@mike actually I had started and then I got stuck in another project and never continued. I understood the architecture though, and I can attach say an Arduino to the SPI and have the EZ-KIT booting from there… that basically replicates what happens when changing program on the aleph. in the end it was all really instructional even if I stopped at some point! do you have something in mind, or want to collaborate?

@alesaccoia @zebra
I would be interested in collaboration but Im afraid that my skill are probably to newbie at the moment. I was interested in working on a device that would be able to creative very flush FM sounds that have shimmering effects I feel when I listen to indian music. At the moment Im trying to educate myself thru PD on the properties of how to create these sounds. I very interested in the sounds produced but the buchla 700 and believe that it was written in C. Also I did see a BF533 EZ Kit on ebay for 50bucks. I dunno if this interests you…

Good deal on the bf533 kit. Don’t need one myself, heh… In fact I gave one away to Scott Harvestman recently, maybe we’ll see more bf533 eurorack soon…

700 was all assembly. I believe I saw someone at Georgia tech had posted the disassembled code recently… If you wanna look. But that’s just control section. Voices were analog.

FM synths… One can only go so far, naively, in digital domain. Waves module is fun. Working on more efficiency == more voices. Getting there

Time is the weapon

2 Likes

wow more voices on aleph would be amazing ! I cant code ( yet ) but can help if other ways if you think of anything. Interesting to know that the voices were analog on the 700. There is a recording I found on the internet some release party for it in a sake factory ? and it sounded soooooooo good !

@mike , yeah I would say that from PD to the bf533 kit it’s gonna be quite a journey :smile:
I will try to get back on this because it’s really interesting. but, get in touch if you need

ps: vintagesynth.com says “The 700 had 12 voices with 4 digital oscillators per voice (48 oscillators!), capable of a wide range of sonic creation including FM, waveshape interpolation and timbre modulation. Filters, modifiers and amps are all still in the analog domain.”

pps @zebra I don’t get notifications to posts even though I have “Send me an email when someone quotes me, replies to my post” active, weird

found the notifications now, no worries : - )

First time I’ve ever read about the Buchla 700. Did a Youtube search. It sounds amazing for any year, but for 1987? Wow. I can absolutely understand wanting to revise/relive that experience.

1 Like

I just bought a BF533 ez-kit off ebay UK, they go for super cheap, really. will continue this soon

hm, well of course b700 waveform data was digitally generated and stored, but i am really not sure which synthesis operations were/weren’t performed in digital domain. (the ‘4th computer’ mentioned in that description might have been some bespoke collection of ICs interfacing with PROM waveform data? i really don’t know.) one processor ran MIDAS, one executed a sort of MARF-like control generator section. in any case it was a truly hybrid system and could not be easily emulated, in its totality, by one program.

i did quite misremember how much of the source code was indeed written in C though. the guy i was thinking of was aaron lanterman and he posted the code here: http://users.ece.gatech.edu/~lanterma/buchla700/
… but IIRC it is mostly MIDAS code, BIOS for the editor, C libraries, &c. do let me know if you spot anything that looks like an FM calculation.

when i next get a chance i will have a look at the schematic as this thread has rewoken my curiosity about the instrument.

2 Likes

@jasonw22 @alesaccoia @zebra

the 700 sounds are super amazing. and my mind has been tripping on this notion of the limits of the digital domain. I love how the 700 pushed the limits at its time with both digital and analog, would love to see/hear what instrument you guys think dose that today. maybe it would be interesting to build many many many differnt analog filters that could in groups shape many digital sources… I love how older snyhts had at times physical spring reverbs… just the idea that interesting sounds where and are found in many places. what would the buchla 800 (or whatever its called) next be. Im personally motivated about how unique it sounded and would love to dream of whatelse is possible.

well, to put it another way, in my totally hazy memory i had a picture of the b700 voices as a collection of tiny processors working in parallel, something like this in fact: http://petermopar.blogspot.com/2015/11/24-parallel-pic-chips.html , funny how things come around. but i was 6/7 years old during its development so not really able to pay attention, the picture could be totally wrong. (if we were on a different forum i’m sure rick smith or someone would be correcting me by now)

analog/digital is only useful in context; here i kind of thought the context meant “implemented entirely in software; easy to copy” vs “implemented largely in hardware; difficult to copy”

4 Likes