#456

it’s only 32 bit so it covers the need for pd-extended for the research and performance/dev faculty presently at Virginia Tech who have a pretty fucking stellar team of devs and music educators.

i don’t really need it for 32 bit because i did the organelle for a few years and i made stuff and instead of pd-extended libs made/helped make tons of historic code work BECAUSE it was 32 bit. My book on advanced pd synthesis will attempt to provide parity from 32/linux to 64/mac/win/linux with an example patch from what i consider “essential” examples of advanced synthesis. That being said the first two chapters are about system setup, sound issues and all the crucial technologist concerns, so when you ask Vanilla or Purr you should really be asking yourself what you want to do with the tool? Run awesome 18year old Ircam Zack Settel code? Incredible physical modelling synthesis from top notch mathematicians perhaps 32 bit might be a place to get comfy and formulate a vision or a Toolkit for your own explorations.

My goal is a cross-platform, historic & cutting edge tool so i need Vanilla but i spend a week setting pd up [at least] for each Operating system. I hope this helps you decide and i think perhaps i am trying to get some momentum going for myself too :slight_smile:

3 Likes
#457

Yeah I’m just building a drum machine to go with the Launchpad so… not so in depth :slight_smile:

Would like to get the a ROLI Light Block working with it too. Got one cheap.

1 Like
#458

Launchpad drum machine is very doable in vanilla.

#459

I’ve been playing around a bit with Automatonism and its been pretty fun, and my aging macbook gets along with it better than VCV. After trying a friend’s Organelle last week I’m tempted to go deeper into it now since I like the hardware compatibility, but the Organelle isn’t great for installation purposes.

Anyone had any experience running Automatonism patches on a Bela? I know its supposed to be able to run PD but I’m not sure given Auto’s particularity about patch saving if it would work. I’m working on something where I’d prefer to use an Axoloti but need to devise a possible back up. Bela in general is kinda overkill, and I’m basically totally ignorant in terms of coding and happy staying that way. If Auto patches could be ported without too much stress it would be a great solution, but since I don’t code its useless to me otherwise.

1 Like
#460

Do you have a Bela board to try automatism with?

If not, I’d be happy to test something for you.

I’m sure it’ll be ok, as I got orac running on Bela without change , and that’s got a fair amount of Pd in it :wink:

Main thing to perhaps bare in mind is Bela uses libpd rather than the Pd app - but as above , I’ve not found an issue with that so far.

The other thing to bare in mind is Bela does not have a particularly powerful cpu, in particular in lacks a decent FPU. Organelle, particular the organelle-m is better in that regard.

Anyway let me know if you any me to test something.

#461

I don’t have a Bela. since I’m not really into coding, so it never seemed as useful to me as other devices so I never payed much attention to it, but it seems like a good solution in this situation - assuming it works though. so, I really appreciate your offer and might take you up on that soon.

for my normal use I think I’d much rather use the Organelle, but since this is an installation that will run for close to a year I need something that can just be switched on each day and run. plus would be such a shame to take an Organelle and just hide it up in a ceiling panel or something like that :slight_smile:

#462

I’m not sure of your requirements, but another option could be a raspberry pi with audio card (like the pisound ?)

1 Like
#463

Can confirm pisound + pd/automationism is a winning combo. i have a pisound box running hacked martin brinkmann patches into automationism stuff and it is very fun

3 Likes
#464

yeah, if you don’t need (very) low latency or analog IO , then I would tend to lean towards rPI+PiSound, bit cheaper and better cpu/fpu. Bela really comes into its own when you want IO and low latency stuff… e.g creating an instrument esp. written more low level (c/c++)

#465

Since I have a Pisound lying around… how do you use the rPI+Pisound combo? Do you hook it up to a monitor or do you use it headless?

#466

I use it headless for the most part. I develop and tweak patches in a git repo on my laptop, and when I’m happy that the patch does what it should I use vnc viewer to connect to the pi and then just update the local copy of the repo on the pi. The pi button chooses between 8 patches.

The pisound is also set up to just read main.pd files from usb sticks automatically, but I found that fiddly in practice.

1 Like
#467

Yes that’s totally fiddly. I did use the app for some time, but it feels like an unecessary, added hassle to me. Also I never got VNC working, and any minute I spend troubleshooting this kind of thing something hurts deep inside me :slight_smile:
Also Pd seems to have a totally different set of problem on linux/ARM than on other platforms. Patches that run perfectly on my mac create all sorts of problems on the rPI.
I think I’m irrationally trying to find a good reason to not sell the thing by bringing up the topic, but I guess I’ll avoid wasting your time further and just stick to my initial plan.

This said, there’s a wider topic here.
Pd seems to have been conceived since the very start to be mostly something you use headless. In practical terms I find that approach to be more than problematic for me. I mean, in theory I really like the idea of not having a screen. It forces you to listen to the sound. But in practical terms, there’s so many things going wrong all the time with Pd that not having a visual feedback is highly problematic.

2 Likes
#468

yeah it’s a pain to get these things set up, but having said that, once I did figure out how to set up the same libraries and such between the pi and my desktop machine, it all worked very seamlessly, and i haven’t had to do any config since i got it sorted out. i use zexy and cyclone libs on both machines for ease of patching.

I was never bothered with the app, just didn’t make sense to me to have to have a third device in the mix to switch patches. All I wanted was to be able to switch between a handful of patches anyway, not scroll and select patches from a gui.

regarding the headless set up - I think the blokas folks spent a lot of time tuning this aspect, and it works very well for me. I use a custom midi controller with hardcoded cc values, and on start up, pd autoconnects the midi device, launches the patch, starts the audio, no issues at all.

I’m on windows, not sure if that makes it easier or more difficult…

1 Like
#469

this is one of the reason I don’t use things like automationism on these platforms.

the way I use PD on things like rPI/Bela/Organelle is that you design a patch for them from the outset,
so you have to decide on what you are going to expose and how, and keep the number of parameters limited - like designing a custom instrument really.
I do agree that some kind of screen is very useful, this is why with the rPI I used the Push2, and then lately Ive been using FATES too…though most of this can be done via midi mapping if users prefer.

as for patch loading… I dont find the button on pisound, that useful…
on FATES ive a simple menu screen (sidekick) ,
but what I will probably do, is as with Organelle and Orac, is support program change messages for patch selection.

what I like PD, is that I can do the a lot of the development on a mac, but I know its going to be targeted to these headless platform - Ive not actually had many issues with this, perhaps because i dont use a huge number of externals?

as for using pisound/rpi for dev… i tend to just use ssh, but i guess im old school… i don’t need these fancy guis :wink:

1 Like
#470

sounds like Bela is the way to go for me then if things work the way I am planning since I’ll need the audio expander. The processing isn’t going to be incredibly complex, basically a very long delay line with some warping effects, but I’ll be using multiple microphones and amplifiers so being able to have 4 inputs and 6 outs rather than say needing 3 axolotis running identical patches is pretty great.

#471

do you mean the Bela Audio Expander Capelet?if so, be careful to read the small print …
I seem to remember the extra input/output quality is not as good as the main input/output when I tried it.

i think the ctag is better ( i don’t have) , but more expensive. note: i think you can use ctag with or without bela

also, I think there are rPI boards that have extra IO too… can’t think of the name of it now… something like injector? also… you can use external USB audio interfaces… though, obviously not as compact then.

#472

yeah I saw that, but a good thing for anyone looking at it to keep in mind. You still get 44.1 at 6 additional i/o’s which is fine for me. running electret mics through some grimy processing, then into class d amps and mini/busted speakers so it doesn’t matter. I often work with patchblocks and crappy little mp3 players so its a non-issue.

that said its always easier to start hi-fi and go low since you can’t go the other way later if need be… so the CTAG capes are appealing. Anyone here tried one out running PD patches?

1 Like
#473
2 Likes
#474

i am looking for a few BETA testers please for the munger~ you really need an organelleM though i am going to post this on the M thread too

1 Like
#475

I’m in !..

1 Like