Building a free modular Synth with BEAP-Modules for educational purposes
Hello there,
I want to create a modular Synth that can "summon" different Modules that should for now be BEAP-Modules. I want to get into the Audio and Bus routing between the Modules later but for now Im trying to create the Modules, that I load into a umenu and then want to load them into the patcher. I don't know why but he always tries to load them from the Applications Folder within Max but I want to use the ones, that I load into the umenu. If the creating in the right size is successful I want to make the Bpatcher movable in presentation while locked.
I hope someone can help me with this, Im still kinda new to this whole Max-Stuff...
Thanks!
http://www.11olsen.de/code/download/8-max-msp-examples/24-moveable_ui
Wow amazing! I just tried it out for one module...works like charm.
Now Ill do it for all 89 Modules and post the update.
Have an Idea or another script for deleting the selected module?
mind you that when you want to move things with scripting, they will have to keep a scripting name after creation, which is a real mess .
11olsen´s jsui solution is the first and only one so far which uses an alternative method.
So far so good. Every Module opens in the right dimensions and are moveable. I also added the NoTitlebar and a window dragger in every Corner cus why not. The Scripts should also be variable to the path where the Device is. before I start with the connection and routing between the Modules you should be able to delete them...if anyone has an idea that would be great. Ill try to inspect my Reference (Oscillot) on how its done there.
Roman, is it actually a problem with what I have right now? Every Module just gets his own pb."Modulename" ID.
max4cats is yet another story, but ask him. :)
(i was just about to ask you why you want to move stuff, where the real problem is making connections in a locked patch)
oh and alternative 4 is to write the complete interface in jitter. then it can look as you wish with no limits.
Alright I probably have to do that because I literally have no idea at this moment..
I thought that I can create something like a Matrix where you just have Dropdown-menus with Audio-Busses in every Module. The Moving Part is more or less just for the user to make it a bit more appealing.
umenus with buses works (technically) well, i have been doing that once to create an enviroment where every module runs in its own window. the names of the outputs would be created dynamically and the input selectors will need to allow multiple choices in the umenu. (watch loops...)
of course it is better for the user to actually see cables, but you know that. ;)
Yes I would probably take that Audio Send and Return Snippet and try to implement it in every Module...
I think cables would just be a bit too much for this project and wouldn't really serve the Endgoal much, at least after looking at how Oscillot does it...
But you're right if I could (experience-wise) and had enough time I would want to implement it via cords.
p.s. i was a bit inaccurate above: audio of course will require/allow also that you already choose multiple targets at the output, so the multi-choice umenu will be there.
Ah right I thought about using that Send and Receive Snippet so you can select to send the Out of idk Oscillator 1 to Audio bus A (should Range from A to ZZ or maybe just numbers but that could result in interferences) and elect the same Input at the Receive for MultiMixer 4 example
Okay so today I created like a Roadmap for all the Inlets and Outlets for every single Module of the 86.
I want to make that happen tomorrow so I think this should work pretty good.
For now I have 8 different Bus-Groups which each has idk 50 Channels: Audio(mono), Control CV(-5+5), Pitch(-5+5,1V/Oct ,sepereated from control voltage), Linear (0-5 Volts), MIDI, Gate, Trigger and Velocity.
Still if that's works like I imagine it, I could still not delete those damn Modules, so if anyone has an idea...please tell me
Thanks!
oh, you have data rate, too? how do you want to handle the order? ;)
when i have a job like this i make a few empty demo bpatchers independent from the existing project and experiment with s/r, var, IO, init systems there.
What do you mean by data rate and order? Probably Im just overseeing something huge...
Yesterday I tried out the whole routing thing with a few bpatchers and it worked fine there. Maybe you mean the right, left, bottom, top order and prioritizing with defer?
I gotta admit, I started with Max this summer with some breaks in between and this hole thing is kinda my first real Max-Project, so Im definitely not seeing some things that are probably obvious...xD
Thanks for your constructive help btw!
data rate == "midi", "velocity"
sending this from multiple places to multiple other places raises the question of message order. (signal doesn´t)
obvious? yeah, i wish. it is actually a bit complicated in your first project(s).
Ah okay I think I know what you mean.
Ill just give it a shot and see if it works.
Well I know for the first project its maybe not the best choice...
Mmh ... it is probably not the best choice for later projects either ... :-)
Last week I tried to build a flexible MIDI routing- and processing system for one instrument and sent and received notes across the whole garden. Actually they went across the whole garden but did not play well after the walk. Instead of "doo dideloo" I just played "krrks chirp ccks" until I streamlined the thing again.
haha, i knew somebody would say that.
well.... if you can make sure that you never need more than say... 16 copies of the same send connected to different targets (so that message order comes to play) you could allow the user to "sort" the outgoing sends as if he was patching a [t i i i i] or something.
a matrix switch or some zl magic will do that.
this would allow him to make connections including controlled message order, while not beeing forced to make connections in a certain order, and you will also be able to move modules around afterwards.
it is just alot of work to find a useful graphical representation for that kind of thing (you would want to monitor it all the time, isnt it?), and it is questionable to use s/r in such a way which requires far more brain work at the user side than forcing/allowing him to patch cables himself.
Haha I was kinda at the same place today...
But that would be some idea, in my case you really wouldn't need that much copies of MIDI.
However I just came to a solution to the closing thing...in the End I just forgot that there a "dispose" message to thispatcher...it even says "*USE AT YOUR OWN RISK*". But yeah otherwise I was just modding all of those modules and Bus sends and receives. Tomorrow there's hopefully the first "usable" Version
So there it is. The first "useable" Version of the Synth. Still there are some window sizes that aren't fitting or the problem that the standard Bus of everything "..." automatically gets signal when the modules are loaded, but Ill fix that post Christmas.
So for now this is just an halfway usable Product and serves more the update purpose of this Thread.
Thanks to everyone reading this and I wish y'all some great Christmas-Days and probably c ya next year!
Hey Guys! Im back with some little updates.
Recently I have connected the MIDI-Modules too, created some kind of coloring for all modules...and checked some other minorities...
Im aware that some Out and Input aren't working properly but Ill fix that while going over every Module that I had planned in detail.
Im thinking if I can integrate polyphony in there but it kinda seems too complicated or what do you guys think?
Have Fun!
Today I just installed some AntiLoop-Functions for every Module that needed it. A wallpaper function got added and some minor stuff. Had 4 example Wallpapers in the Folder so 5mb not going to fit here... https://we.tl/t-3qXftfR0r5
No update from me for a long time, but Im still at it.
Right now I working my ways thru all the modules finalizing them and making sure that eveything works.
Today I got a bit excited because I think I can implement VST support and the ability for the whole thing to be saved in your Live Set as it is.
I will continue and post an update as soon as its ready!
You can also use a panel with the drag_window attribute set to 1. Simpler and faster, but less flexible, than the jsui option
Good idea, thought about that too...
But you're right in the end jsui is more flexible
that [panel] option is great when you give the user a uniformed position and graphical representation of the "handle", say like top bars of operating systems do.
Im currently putting on the last finishing touches but there is one big elephant in the room...
I want the whole thing to be saved in a Live Set or in an internal preset.
Now saving the parameters is not the problem but first of all seeing the parameters of created modules for ableton automation and saving the bpatchers in the presentation position and recreate the set of bpatchers loaded to the Synth is kinda giving me more head scratches than I thought....
Currently I can save presets with the pattrstorage and save everything I need inside of the patchers and what UI Elements are shown and stuff but the automations in ableton of each module are just available when they are already in the Synth when loading it. Also I don't really know how I can save different states of bpatcher positions and which modules are spawned and not
This will probably be the last time that I will ask for serious help here before I release this thing so please have a look:
https://we.tl/t-tekVOADJMT
If the link is not valid anymore I can post a new one at any time.
Thanks to everyone who helped me with this!
Hey there!
The Beta is done and I just want to drop it here to kinda conclude this thread.
Thanks to everyone again and I hope you like the result.
https://forms.gle/VREvpq5B7YF5n5ZPA