#1

There are now several sound synthesis HW systems:

I realize these cover a pretty wide range on many axes. Has anyone put together a comparison chart? Or have I just volunteered myself…?

5 Likes
Monome, embedded systems, raspberry pi, pure data and whatnot -> :-O
Old organ pedal board - MIDI controller ideas
#2

:wink: it would appear…

1 Like
#3

And don’t forget:

The use of Linux (or not) is one big thing that is different between some of the things and other things on your list. And Bela is the only one of the list that uses Xenomai (for very low (1ms) latency), to my knowledge?

I’m interested in Linux because it opens the door to multiple synthesis engines. But I’m concerned about complexity and latency. So I like Xenomai, which is why I have a Bela. But I haven’t really done much with Bela yet, because it feels a bit like early days of Linux: gotta build my tools before I can use my tools.

1 Like
#4

Discourse is barking at me for replying so many times. Sorry Discourse.

Some handy threads:

3 Likes
#5

Just to throw another option in the mix there - it’s not comparable to the others in that there’s no existing hardware which I know of leveraging the technology…

At work I’m using a lot of faust code for DSP prototyping. And we want to deploy the prototype now! I’ve settled on the ARM Cortex M7 as a potential bare-metal host for faust code, and got the provisional go-ahead to open-source templates allowing deployment of any faust code the the M7. This is the board I’m using:
http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-nucleo/nucleo-f746zg.html
but still struggling to establish first contact from usbstreamer i2s interface to the M7. Anyway - this technology gets me kind of excited if I can wade through the diabolical plumbing & get everything hooked up right!

2 Likes
#6

bela and axoloti did a bit of a comparison on their websites
http://bela.io/archive/faq.html
http://www.axoloti.com/more-info/comparing-axoloti/

there are also a couple extra I would add, including a PI with an audio interface like hifiberry, and then more diy solutions including using STM discovery boards, or something like an X15.

they all cover slightly different bases, and really aim at different users…
to the extent if you know what you want to do, is likely only one of them will be really suitable, as the others will be ‘lacking’ in an area.

I suspect the major differences are:

  • latency (real time or not)
  • software support, and ease of use and integration.
  • openness in hardware
  • raw processing power

note: Ive only been programming Axoloti, Bela and PI+Hifiberry , the others i only know by hardware specs/manuals/forums etc.

1 Like
#7

yup! So can anyone on here know a simple recipe to hook an i2s DAC/ADC pair up to these boards, including code, i2s pins etc? This thread reminded me the axoloti is based on M4 so maybe I can pillage their github for clues.

Tearing my hair out over example code most of Thursday and Friday - finally got things compiling/deploying outside the horrid free eclipse toolchain supported by ST (i2s project example eclipse project also borked), flashing LEDs etc but still not a peep out of the the M7 i2s or spi ports…[quote=“TheTechnobear, post:6, topic:4481”]

  • raw processing power
    [/quote]
    M7 has an fpu & axoloti’s M4 doesn’t, hence why I expect the particular combo faust/M7 will be particularly tasty and a pretty different beast from aleph…
#8

yeah, for my ‘power’ combo, I’m using BBB + Bela, A8 at 1Ghz is nice, with Xenomai and its PRU code its also low latency and seems jitter free (so far)
(btw: faust already supports bela … (or is that the other way around?!)

with axoloti I treat it differently, more modular, using different boards for a particular tasks eg. sequencing, fx , instrument… this is going to soon be much easier as a digital link between boards is being added, (currently in dev firmware) … this will allowing passing of both audio io and midi io between boards.

1 Like
#9

ha - unfortunately I can’t get my grubby paws on a bela for now. Missed out on the kickstarter, partly because I was somewhat offended by the heavytools non-free software and didn’t want to support that aspect of the project…

Since I’m now quite heavily invested in beaglebone platform from controller-side, I will probably just buy a bela when the next run of boards becomes available - no point cutting off the nose to spite the face.

This reminds me I should hack more on aleph host software - a liblo C program to expose bfin DSP params over OSC would open up my work on BEEs ‘digital link’ to many more people, which would be awesome!

2 Likes
#10

I don’t think they had any involvement in Heavy, its just one way of using bela, alternatives are C++, libpd, faust, supercollider… I think its been more down to who offered to support the bela api.

1 Like
#11

Googling around, it seemed to me many of the same people were involved in both projects, and that a big selling point of bela during their kickstarter was heavytools.

However, my intention is certainly not to flame bela (or, for that matter, anyone who pragmatically chooses non-free software for music creation), especially seeing as bela website now has no reference to heavy tools, rather it points to a GPL3-licensed repo on github. Like I said I’ll probably jump on the bandwagon next run of bela pcbs for hobby/music hacks.

Can beaglebone black i2s slave to external master clock? at work we also need to interface to fpga, not just analogue - a DSP host that’s equally happy in i2s master/slave seems like a no-brainer to me and pretty sure the M7 will tick that particular box…

#12

interesting timing

just traded gear for an organelle and spent most of the weekend comparing its strengths and weakness in relation to aleph

it hasnt arrived but i’m salivating at the prospect of using them in tandem and cross-polinating ideas from both worlds

5 Likes
#13

My take on this is embedded linux is ‘the right thing’ for control, and bare-metal is ‘the right thing’ for DSP. hacking on avr32 without high-level languages and advanced debugging is very frustrating, as is a ‘state-of-the-art’ soundcomputer which cannot do single-sample latency when told to do so!

2 Likes
#14

Comparison spreadsheet started: Reconfigurable Sound Hardware

In the spirit of collaboration, it is open for editing: Make it better!

3 Likes
#15

where did you get the freq response specs for aleph?
i didn’t want to contradict you but if we’re listing maximum possible I’ll correct it

if we’re using actual response based on measurements or benchmark tests then i have no idea what’s been implemented so far

#16

I pulled the information from the Aleph page. If I got it wrong, correct it.
In some cases the specs for the HW and the implemented SW are different - like on the Axoloti. In this case, I entered the system as implemented - and added a comment to the cell with the HW maximum info.

If you have measurement data from your system, then add that as a comment on the cell, or perhaps add a section of rows at the bottom on “Achieved Results” or some such.

#17

Ah - the Aleph page is ambiguous:

Under the drawing:

audio 4 input, 4 output, 48k 24bit

Under the development heading:

audio codec:

  • 4 channels in, 4 channels out
  • up to 192k 24bit
1 Like
#18

ah i see that too now and totally forgot

i’ll fish for details in the archived forum but @Galapagoose @zebra @tehn do ya’ll have an explanation?
not urgent btw

#19

how about the shbobo shnth?
I beleieve shbobo will have another instrument coming out in the future as well…

3 Likes
#20

Was going to mention the shnth. No idea how to fill out @mzero’s spreadsheet for it though!