Max/Msp native synth

I wanted to ask if other share my problem that is, I develop multimedia under Max/Msp/Jitter which is limited because of the luck of a powerful synth running native under Max. I have to use VST related products which can not be included in building Max applications. Developing a synth myself is to hard to do and I wonder if there are some specialists out there who succeeded building a synth under Max5 or would like to see one being build?
I use the Absynth from NI from time to time and found the layout under ‘patch’ very convincing. It could serve as a model….

A while ago, I tried to put together some generic synthesizer parts so that I could just drop an oscillator into them. It turned out to be a buggy, bureaucratic mess. I don’t necessarily believe that it’s impossible to build a high quality fully featured synth in max, but I do think that if you did it, it would take 70% cpu and wouldn’t fit into most workflows. More importantly, I have a theory that there is something about the format that severely discourages modular systems. Programming audio is so strange because it *really is* 99 perspiration.

I normally make small little things in Max. If I want a fully functioned synth I use hardware or I have VST~. I do think it would be good though to have a few simple but powerful abstractions though. I really liked the series of LFO articles by Gregory Taylor as they built up to create a very powerful modulator which could be used in a lot of different projects. I think it would be a good idea to do something similar for oscillators and filters. Below I made a list of the general functions provided by the Oscillator and Filter Module in Absynth as an example. Maybe Jamoma does this I have yet to try it out.

AudioMatt wrote:
"I don’t necessarily believe that it’s impossible to build a high quality fully featured synth in max, but I do think that if you did it, it would take 70% cpu and wouldn’t fit into most workflows."

i think this is just conjecture. it is very possible, and you don’t need to go to 70% cpu if you use poly~ smartly enough to mute portions of the DSP wherever not in use and possibly also if you used javascript, etc. to script the appearance and disappearance of modules. hard to say for sure since none of us are the creators of absynth or massive or anything like that… but consider Miller Puckette’s smeck:http://www-crca.ucsd.edu/~msp/

i helped a certain company implement that polyphonic string synth/processor in Max. it is no small synth app. putting each separate part in a poly~, allowing for multithreading, and dynamic DSP allocation… you can get away with quite alot… if you actually know the full capabilities of Max/MSP… otherwise, yes, it’ll seem like a huge unuseable mess once you’re done, but might that possibly be due to your own lack of info. and knowledge? NOT max/msp capabilities?

plus if we all learned how to write externals to expand Max it would become increasingly easier to accomplish(this is part of the body of knowledge of Max. people who don’t go far enough to learn this part of the Max experience are not embracing the full extent of what’s available with Max… anyone can program externals in C(or even C++) with the help of the Max SDK… it’s really not that difficult but most people are too intimidated to go there at all… it never has to do with the difficulty of the task, only the fear of it). i only say this because if you don’t program your own Max externals(or at least try to get to know some of the basics of the SDK and how MSP and Max objects work), then you can’t make a fully informed decision about what’s possible even using the standard included objects alone.

hans wrote:
"I wonder if there are some specialists out there who succeeded building a synth under Max5 or would like to see one being build?"
I say go for it!

I’m not getting into an argument about my level of knowledge but I have read the help file for poly~ which is most of what you alluded to. Obviously my statement was conjecture. I apologize if that wasn’t clear. I thought it was since I said I hadn’t done it. I would absolutely love you to prove me wrong and give us all a usable synth patch that we could rip apart for our own purposes.

so… I *doubt* but am open to the idea that I’m going to get the entire virus in max and still be able to use it in context with something else.

I took for granted the notion that if you program an external, you’re not implementing your code in max, it’s in C. So that’s what I meant. Of course it will run at C speed and of course almost anything is possible. I know C and I’ve been meaning to install xcode and give it a shot, but for now MXJ is fine. I’d rather focus on art for the time being since I’ve spent so many years obsessing over programming oriented projects.

"most of what [I] alluded to" is not about poly~, it’s about Miller Puckette having more knowledge than all of us combined and therefore proving that it is a matter of knowledge rather than system capability.
"I would absolutely love you to prove me wrong and give us all a usable synth patch that we could rip apart for our own purposes."
I just did by mentioning implementation of MillerPuckette’s Smeck in Max.
(PD is not that difficult and I can’t give you the original Max patch I helped a company with because that’s obviously a trade secret… but now you have the info., get to work! it’s actually not that hard once you have the DSP already worked out by Miller…)
if I see someone saying something I believe is absolutely wrong, I’ll point it out. it’s my right.
"I’d rather focus on art for the time being since I’ve spent so many years obsessing over programming oriented projects."
Programming IS art(if you’re a digital artist, it is definitely part of your art)… so maybe you were unable to come up with something useful for youself because you have the wrong idea about art… (going off of your own words, i would absolutely love for you to prove me wrong and list all the ‘programming oriented projects’ you’ve done which would make you an expert on what max can and cannot do(even while the full capabilities of max are too infinite for any one person to know))…
my comments are addressed to all in general starting with your quote only as the introduction…. you shouldn’t take yourself so seriously, then you won’t take the wrong things personally ;)

I’m trying pretty hard not to be open and not combative, in return, please try not to be demeaning. We’re all here to learn. By all means, let’s all work on a high quality modular synth patch. I’m game.

where’s the anger? you must be a midwesterner to jump to conclusions about people so quickly. seriously, my words(prior to this post, anyways) don’t show any in any literal way(i do get sarcastic, though, in general because that’s my personality, i shouldn’t have to filter that just because of some notion of conformity that you might have about these forums), but of course you can infer anything you want if you’re prone to eccentricity like most of us tech people are, anyways, i don’t have a problem with that, either(and i edited the ‘sir’ because it was too sarcastic, decided i would edit out of respect). you shouldn’t put words in other people’s mouths(that’s too American, with its quickness to judge and jump to prejudice: I know you’re smarter than that… maybe not…). and that definitely makes you hypocritical when saying you’re trying not to be combative or demeaning. i was just asking for your list of projects and i feel inclined to disagree when people say Max can’t do something that I’ve seen done. Plus, I’ve seen all your patches on these forums for quite awhile, they seem intermediate, like maybe you still have quite a ways to go before you know the full capabilities of Max or any DSP environment at least in comparison to people like Miller Puckette. That’s all. It’s not an insult, just truth, a truth that is true of myself, too!

There’s no anger here, just a fun little bit of sarcasm when i notice someone with pride speaking about things they don’t really know about. I may have a dark sense of humor. My apologies.

But you shouldn’t scamper away from every little confrontation(I understand your eccentricity, though ;).

Here would be another great place for some benchmark information about various objects, especially CPU-hungry ones like biquad~ (I’m assuming it is…) The best thing would be to be able to track all objects for their processing loads, or even whole subpatches, compare poly~ vs. non-poly~ implementations, etc. Maybe it’s not possible directly, but having a few categories (light, medium, heavy CPU loads) and lists of objects which fall into those categories would be very helpful when designing. Not to mention the other processing loads created with UI elements like filtergraph~. Possibly for many of these objects or functions, there are attributes or parameters which could be minimized to still get what you want (or at least close) and save a ton of CPU, I don’t know…

Coding your own externals would likely give you the best results, but generally they’re not as straightforward to do as patching (depends on your area of expertise of course), plus they’re not immediately cross-platform, and you have to include them in whatever package you’re distributing. Not that these are deal-breakers, but they are considerations.

With the relatively safe assumption that computers and audio/video hardware will continue to increase exponentially in performance, I say make your synths in patches, and when they reach the limit, cut them back a bit so they work without glitching. Then relax and realize that in a few years your patch will run back at 25% rather than 100%…

well put, seejay
(… and i thought maybe i should just say that i didn’t mean to imply that coding externals would be more efficient all around, just that the knowledge of the SDK(of how objects work internally) will help to inform one more about efficient patching: for example, knowing MSP’s way of working with a ‘perform’ method would elucidate more about vector-specific poly~ usages, etc.)

"i think this is just conjecture. it is very possible, and you don’t need to go to 70%
cpu if you use poly~ smartly enough to mute portions of the DSP wherever not in
use and possibly also if you used javascript, etc. to script the appearance and
disappearance of modules."

have you ever tried to build a synthesizer voice (poly~) in maxmsp?

if you make f.e. a simple sampler with 2 envelopes and 2 biquad filters in maxmsp and
compare how much CPU it requires when you run it under metro conditions (so that
it responsiveness to data input is comparable with protools or cubase) and with
a vectorsize of 32 (so that is comparable with protools or cubase) you will find
that the same appliation made with maxmsp will take like 3-4 times more CPU.

there are several differences between programming "native" VST plug-ins and writing
similar code in max, starting with the lack of basic techniques like multirate audio, which
are a no-go in max (except using poly~, which is limited to downsample by multiples of 2)

you also do not have an unlimited number of priorities for data, you have just 2 or 3.
complex rules for priority or event order are impossible (or to be exact, very different
from C++ programming)
order of execution in maxmsp is always linear – you can not, for example, use
custom systems of round robin, throughput limiting, data slew, making up
whatever complex rules for "defer" or not to "defer" or for the order of output.

last but not least, if you build a synthesizer [poly~] with envelopes, modulation
modifiers, filters and releated processes (FM, AM, RM, PD, summing, gain and all
these things) you would need to create all these things as [poly~] supatches inside
the main [poly~].
and working like this makes maxmsp programming very difficult, things are getting
unstable, you can easily loose overview about subpatch versions, locations, and
if they are up to date or not, and in the end you can only turn your subpolys only
on and off by messages – and not by signal.

the idea of having an [absynth~] external in maxmsp seems absurd, this is the
opposite of what a programming language should be used for.

i gain most fun and productivity out of maxmsp by creating something myself.
sure, sometimes it really sucks that it is so f*cking difficult to create a simple
sampleplayer or controlling and routing midi input with maxmsp.
and i also find it quite frustrating that VST effects (yet not instruments) do require
2-3 times more CPU in max (at smmall vectorsizes) compared to DAW hosts.

but if maxmsp came with [absynth~], [gigasampler~] and [finalcutpro~] i would
definetly never have started using it.
there is absynth, gigasampler, and after effects to do what they can do.

"and working like this makes maxmsp programming very difficult, things are getting unstable, you can easily loose overview about subpatch versions, locations, and if they are up to date or not, and in the end you can only turn your subpolys only on and off by messages – and not by signal."
haha, so true, i didn’t say it was easy. (and programming externals can help pick up the slack on signal limitations, etc…. i just think that people don’t realize, if you’re programming in max, you may not be programming in C or C++ or Java(in MXJ), etc. but you are still using the thinking and methods of those languages so it’s not that far of a stretch to actually go and learn the roots)

also, absynth was only posed as an example model of where to start from. no one is talking about creating an absynth~ object.
(edit: I’ve taken a look at the monstrous 110 app you are the dev of, i find it hard to believe that you would complain about anything being difficult? ;)
but Roman! I like your post. I love this thread. Brings out the thoughts in every1 in a nice direct but effort-filled way. Thanks!

haha, Brendan, don’t be so easily spooked(and if that law were true, consider your own part in directing this thread there). we’re just discussing possibilities and there’s nothing wrong with having a little passion over what we do. (besides, this discussion isn’t even close to being ‘long’ ;)

here’s Noob’s law, though: "As an online discussion grows longer, the probability of a sense of ownership and ego stifling any sense of diversity approaches 1."

(edit: no disrespect to you personally, though, Brendan! i like all your posts…)

haha, best compliment ever! thank you! (admittedly, online personalities to me are like compartmentalized masks that will inevitably turn out schizophrenic compared to real life: noob4life is a chance to be direct(only a fragment of my reality). so maybe i should post a disclaimer, first: my ‘direct opinions’ are not always ‘personal opinions’, in that i hope no one ever takes them personally, nor even too seriously ;)

moving forward, maybe we should take a closer look at grizzle’s mention of Jamoma, there’s quite a bit in Jamoma alone that can facilitate synth building(not just the tools but the standards of development they’ve established). i will take a closer look there… see what i can find…

surely "confrontational" is a compliment between us here there is no doubt.

when you like it to disagree with things, you will have to respect those who
offer you all those wonderful wrong ideas worth to disagree with.

@noob:

110.modular might _look impressive (to noobs?) and it is probably one of the bigger
projects you can find around.
but not difficult for me? well, there is lots of crap code inside which other people eventually
could do much better.

it is probably quite innovative and all, but there is for sure better code on this world
than mine, and some of the things i actually had to research, or had a hard time finding
the right expression and optimizing the functionality until the stuff did what i wanted.
a few of the modules even contains concepts (i.e. original code) i had to copy from others.

if my skills would be better, there would be about 300 more modules, that i swear.
it is only that limited and still a beta crap project because noone can do anything easily.

and coming back to the original topic; the audio modules which were coming with
110.modular are more or less bullshit, really, some of them did not even work at all
when released.
of course i have much better audio patches than what is in there, yet there is a
reason why i couldnt not yet make better stuff available with it, and it has among
other things (my personal CPU limi, my taste, that i use max version 4) a reason, which
is my skill limits.
the reason for the lack of better audio modules is that i simply cannot decide how
to build "my" final method of making a sampler or synth. it is just too difficult to find
a "best" personal standard poly synth system.
the sub-poly problem we were talking is the main reason why i use, when i am composing
with the modules, mostly custom on-the-fly pre-alpha patches – or VST plug-ins.

not absynth though, i find it even as a software project too complex.
delay and reverb should get the f*ck out of synthesizers. please!

I used to enjoy a lot this kind of debate in sc mailing list, and max people do the same, it’s great! so interesting to read…

I’m just stupid shit newbie so I have nothing to say, but the most part I agree with Noob and Roman T.

as I’m a stupid shit newbie, I spent last six days to build something that is a…wow! a "step sequencer" (with drag and drop function)!!

but I don’t think it’s waste of time. ‘efficiency’ and ‘productivity’ or ‘powerful something’ are words of diseases from our capitalistic society. I bet if you have 8 [absynth~] running in your machine with only 10% of CPU, you’ll still make crap music if you don’t have right creative mind. and the most wonderful house track I’ve ever heard was all made with "Rebirth" on pentium II.

go make some art instead of trying to sell some "new"(yeah, "new" huh??) softwares. we have enough.

and don’t develop further ‘max4live’, I didn’t pay my money for you people do marketings.

I think that there is a lot of software around which has particular strong features. The advantage of Max is that it is an ‘open’ system. I can only say that I was surprised to see the ‘patch’ window the first time of Absynth and I would recommend to everyone who wants to think of DSP to have a look at this architecture. I am still always so grateful when I come across something that talks to me on that level.
If there would be a new bread of objects coming which take into account what is ‘good DSP’ practice why not embrace it? FM took a while to come to maturity too.
Hello David Z what do you think of a native Max/Msp synth? What are the odds for you?

AudioMatt is right, Max is not best suited to synths. Calling his knowledge and character in to question isn’t wise either. The board is for learning – Not code based cock measuring.

Anyway, I have quite a few synth patches lying around which are mostly simple waveforms and filters. For me this is all I need as I’m not a fan of fancy waveforms, the whole press one key and go to neverland type synths make me a bit queasy actually. For the time being I’ll stick with saw~ rect~ and the like, as I don’t have the skills or the time at the moment to get in to bandlimited waveforms and all the jazz (I did post a topic about this, but without examples I have no clue).

Hans – Why don’t you have a go at this synth and see how far you get, while I don’t think its always right to copy something in Max, this could be a useful learning experience for us all.

i’d like to vote to mr. grizzle’s idea of building a decent-sized synth that suits the project each time. absynth is a very versatile synth that is designed for varieties of musical situations, and i’m not sure if you need that full functions of full-blown synth every single time.

the advantage of max, i think, is you can build what you need each time.
(good for CPU, good for earth…, maybe)

i’m not too familiar with the structures of absynth’s patch, and i wonder what fascinated mr. Hans so much in detail. i have a feeling that it maybe duplicable somehow in max as well. (DSP part of max or MSP is, in my opinion, very well designed and rich in content)

but i agree with mr. Hans here that max lacks a good library of easy-use synths like reaktor has. a collection of abstractions that can be loaded to [poly~] would be nice too.

and i think you are right. max has all it takes.
looks like absynth is, in bare bones, three wavetable synths with filters and modulations.
(with, of course, a very rich library)

to be honest, i was surprised by its simplicity. as far as the structure goes, it’s very straightforward, almost analog-synth-like.
(there are things i don’t see, for example where lfo and envelope comes in, which seemed to play a big role in the morphing sound. and i hear a lot of delay and reverb too, which wasn’t clear where they come from)

i think from what i see in those videos, most of the sound is duplicable by max.
but in order to build one in max, you have to know what you want to build beforehand, unlike absynth where you can play around to see what you like, which is absynth’s huge advantage and which you might find it so fascinating.

"AudioMatt is right, Max is not best suited to synths. Calling his knowledge and character in to question isn’t wise either. The board is for learning -"

First off, the way i see it, there are people who were supportive of the synth building idea here, and people who are just plain unencouraging. This is not right or wrong, simply positive and negative. I am one of the few who are supportive(Mike S, if you use cuss words, you only prove that you are not an authority on matters of character nor of using this board for ‘learning’).
I did not call character into question at all(but rather state an answer about how all our characters fall apart over nothing, and that Miller Puckette’s learning proves easily that our general notion of expertise and knowledge is still only relative to what we, ourselves, do NOT know). Don’t be so easily spooked by all the words that seem to call up associations to your mind in the same paragraph before you actually understand where they are going and what they actually say outside of the associations you normally draw in your mind(i might not make those same associations with words). In my experience, Americans, not British, are the worst at understanding the english language because so much about how we, Americans, speak, is locked up in over-stimulating advertisements and inflammatory politics(as well as the need to be ‘cool’ which is what the music industry in this country tainted our young minds with as well).

I ALSO APOLOGIZED TO AUDIOMATT! that should have been between us, so Mike S, you are now just being rude and inflammatory, much like any politician(again, not an insult, just a truth about similarity of action… NOT of character).

As for questioning knowledge, there is nothing wrong with asking people to consider(using the word, "maybe") that they might not be the expert they think they are when they take a step back and compare themselves to people like Miller Puckette who, i believe, CAN prove everyone who believe "Max is not best suited for synths" downright wrong. If AudioMatt and Mike S had read carefully, they would have seen where I wrote the same "maybe" addressed to my own lack of knowledge.

If you don’t believe Max/MSP is worth trying to build a synth in, why join this thread at all and discourage people who will simply try anyways? In the end, it just makes the discouraging people look like bullies. That’s all there is to it.

(you must’ve read some of it, Mike, i can tell, nobody writes ‘tldr’ without actually reading… in any case, don’t be so easily frightened of reading, but i can understand your adherence to the convenience of a cut-and-run tactic, being an American myself. but it is cowardly… no matter who does it… that’s not an attack on your character just on the tactic ;)

you wrote: "How about we get started on a community project?"
i think you’re not understanding that we’re already on it, despite your previous attempt to derail us…
fair enough… i’m still looking at Jamoma…

EDIT: @Hans, David Z doesn’t always read everything on these forums or at least doesn’t reply if you address him, according to my recollection… probably because he is too busy or something… the rest of us can try to help you best we can(particularly if you come up with a starter patch ;)

Thanks for all your thoughts so far, I am very pleased to have started this feasibility study. I think before we jump into the cold water, we should try to attract some more specialists and hear what they have to say. In the end it will save time to have good advice. I would like to hear what Timothy Place would say for example. Also, I am not a good programmer. Please do not think I could invent a synth running under Max but the architecture of Absynth really talked to me. An oscillator unit a filter module and a modulation is already very good.

I recently participated in a brief forum-collaborative project, maybe some of you remember it; the project ‘Director’ established some great guidelines/constraints – (un?)fortunately it was short-lived and didn’t produce a final iteration (or did it?)……… this thread is VERY exciting and could perhaps culminate in the type of synth the main protagonists are alluding/referring to…… I might just watch from the sidelines though……DSP vector sizes, polyphony, multi-threading et al scare math-noobs like me; but I might chip in some granular/FM synthesis stuff.

I just want to clarify that this is not a side A side B debate between for/against a max synth. I’m on record as saying I would love to work on such a thing. (In fact I think I was the first to suggest it in this thread)

I’m skeptical but optimistic.

The thing I’m skeptical of is routing in a locked patcher. too many zeros being processed with not enough results.

But… A smart guy recently told me that it might be possible to program an external to arbitrarily insert a patch into the DSP chain without interrupting audio. This means not processing zillions of zeros a second.

I have a simpler idea I’ll present in a half our or so that, I think, will get around the multirate sampling that roman talked about.

don’t be so irritable, MikeS, i’ve seen your patches, posting one cycle~ object is not much help coming from someone as knowledgeable as you… are you perhaps being a bit facetious?
if not, could you add your famous pong~ syncing envelope generator to the cycle~? from there i’ll take it and add wavetable loading to the cycle~… but first i’d really like the old pong~ syncing adsr thing you did long time ago…
please add it to the patch you’ve posted, Mike.

EDIT: thank you for returning AudioMatt! I am looking forward to learning from and tweaking your patch.
p.s. who was the ‘smart guy’… can we see some of his code? i mean for the dynamic loading/deletion? really want to try this…

Unfortunately poly doesn’t work for routing audio because send and receive don’t work in it. What I’m talking about is assigning an LFO like a normal synth without sending zeros to 30 places.

Think about it, if you’ve got 2 LFOs, 2 ADSRs and 30 targets. you’re processing roughly 5.2 million zeros a second just to route them not including the scaling that needs to be done for each target.

poly~, unfortunately, doesn’t really help with that.

If however you had an object at all the target which knew when to process and when to just fill in a precomputed vector filled with a default value, you might save a lot of computing power. You could just copy a zero vector to the output of what ever is distributing the weapon signal.

Same thing for adding signals from multiple weapons, If you know weather to process them or not, it saves the external from having to iterate and add all the zeros.

Even with all this, you’re still puting a sig~ object at every destination in your synth. That’s expensive but it does save quite a bit of calculation.

This thread is a good example of "your perspective defines what you see," I think. There seems to be lot of heat, without a lot of light.

There are a variety of simple synths already made for Max/MSP. I think a simple fixed architecture synth can be made in Max that doesn’t use a ton of CPU. IMO, the problems start creeping in when trying to make something too general & flexible.

An example of a simple synth, called "Simple FM Synth," can be found on my Max page.

AudioMatt wrote: "I left off the tildes. sorry. "
no apology necessary, but you can use send~ and receive~, too within a poly~(setting names dynamically with arguments to poly~ or using ‘set’, etc.)… they are actually easier than the non-tilde because you can set their names dynamically(unlike regular ‘send’)…

EDIT: Chris Muir’s "waste of space"(as he called it) webpage full of synths made in Max/MSP is one of the reasons why i was so adamant about underlining the possibilities.

This is not the most astute example, but attached is something that shows how you can use send~ receive~ inside a poly~ with 2 different methods of dynamically setting their names. It’s not the start of a synth for this particular thread, but just in case it helps understand poly~ better(or helps me understand the criticisms of poly~ better)…

I’ll leave Tim or any other dev more familiar with the Jamoma framework’s code than me to bring more details etc.

That said, the Modular branch of Jamoma contains a number of patches designed as modules. Although they’re not specifically built with a synth oriented approach, a number of them could certainly be used to make a synth. And as mentioned earlier in the thread, the Jamoma Modular framework could make some things easier without a doubt (parameter, message implementation, preset management, etc.).

Moreover, a number a modules use some Max objects built on the Jamoma DSP framework which could come handy. The Jamoma DSP framework (like all other branches of Jamoma project) is available thru github : http://github.com/tap/JamomaDSP

Noob, did you try re-assigning that send~ void inside the poly? For me the signals gang up.

the patchername message also crashes my machine. So I don’t see a way to turn off sending from there.

Maybe I’m missing something

As for Chris’ synth. I owe him a ton of respect. He’s helped me a ton. It’s an awesome example but at 64 samples/vector it tops out at 17 percent, has one LFO and is 4 voices. I hate to say it but I think that kind of proves my point.

Attachments:

"Noob, did you try re-assigning that send~ void inside the poly? For me the signals gang up."

this is not necessary, all you have to do is re-assign any receive~s(even outside the poly~ if necessary), then dynamically send~ing can be handled outside the poly~ anyways(i’ve also come up with a workaround before using selector~ and a bunch of prenamed sends~ within poly~…sending 0s everywhere doesn’t actually take up much CPU(this is what mute~/pass~ does when saving you CPU(non-poly~), anyways)).

patchername message doesn’t crash my machine at all!

also, i don’t think 17% proves anything(you can add quite a bit and have it remain at 17%, 17% is not huge, anyways), but i’m hoping to see your point or perhaps work around it since we’re all going to come up with a good synth no matter what other’s complaints are…

I DO find the mute-stuttering to be interesting, though! will have to take a closer look at that…

Noob, I may have made the same mistake you did. I opened up the supatch and edited the poly to 32 and it stuck at 18. which didn’t make sense to me.. So then I edited the argument to Simple_FM_Synth to 32 instead of 8 (I didn’t catch that) and the CPU is sitting at 48% and peaked at 90%.

as for the send/receive stuff, I’m not sure I understand what you’re talking about so let’s do it! I’m down to learn!

cool! i’m going to use what you said as part of a model: "if you’ve got 2 LFOs, 2 ADSRs and 30 targets"
i’ll try out creating 2 LFOs and 2 ADSRs and attempt to apply them dynamically to a synth(not necessarily 30 targets but more than one to start for sure).
might take me a couple days(have other stuff to finish as well), but i’ll post what i find soon enough… (or if anyone else comes up with anything in the meantime and posts here, i’ll try to work from there…)

If you want any help let me know. As long as I’m not repeatedly insulted, I’m really interested in doing this. (That’s why I commented in the first place) Experts here talk about reinventing the wheel a lot but I’ve never seen a synth with one input per voice. It could be groundbreaking if we amassed a decent library of oscillator modules. While I remain skeptical, I’m down to learn.

I want to add one more thing. Originally we talked about externals vs max. While my interpretation mattered at the time, I don’t think anyone who wants to see this cares if there are custom externals involved. It’s a project, not a challenge. I’m not going to sit here and belittle you for "cutting corners" and getting better results for the community.

"It’s a project, not a challenge. I’m not going to sit here and belittle you for "cutting corners" and getting better results for the community….
As long as I’m not repeatedly insulted, I’m really interested in doing this."

Agreed! (I have learned from this that while my intent was never to belittle, my ‘blunt’ communication does not always end up necessarily being the ‘direct’ or ‘honest’ communication i had hoped for. :) )

"never seen a synth with one input per voice"
i’m not sure about the necessity… i mean, i’m not convinced that the sound would be something as diverse/detailed as the technical description… often a complex waveform created by 3 or more inputs might actually be created with only 2… in other words, it’s not necessarily the expansiveness of a synth’s input stage that determines its usefulness and flexibility imho

been going back through poly~ tutorials and examples, and i see the X.FM~ example is actually a great start(must be relatively new or maybe i’ve been putting off looking thoroughly through it until now…)

granted, it can get up there in the CPU, but am just wondering where we should draw the lines… obviously, i don’t want to build absynth… there are things about it which would obviously make its overhead dedicated to exactly what it needs to do, whereas the same thing in Max seems it would be more a demonstration of capability(not of efficiency).
starting with this x.fm~ stuff, we could take yafr~ out of the equation and that would save some… we could set poly~ for multithreading/parallel-processing and that would save even more on many comps…

anyways, anyone taken a look at this yet?
it seems to pose a good answer/starting-point to this thread:
Max5/examples/synth/FMSynth/X.FM~.maxpat

"What I’m talking about is assigning an LFO like a normal synth without sending zeros to 30 places.
Think about it, if you’ve got 2 LFOs, 2 ADSRs and 30 targets. you’re processing roughly 5.2 million zeros
a second just to route them not including the scaling that needs to be done for each target.
poly~, unfortunately, doesn’t really help with that."

well, nothing will help here, it is unavoidable.

in any electric circuit and in any computer program you will need to make 30 connections
when you want to put a global modulator onto 30 voices.

the only thing one you could do is that you only send the modulator to those voices
which are currently playing, and that is possible with poly just as with assembler code
or automatic switches in a circuit.

@hans:

the basic structure of an absyth voice is kinda classic i would say, most synths work like that.

("without sending zeros to 30 places…."
was trying to say before that writing externals(as new to it as i am) has taught me that sending 0s to 30 places doesn’t have to be a big CPU concern, anyways: a 0 output at the end of a perform method(written in C or Java or C++) is nothing big… it’s actually better than the DC offset that might occur if you shut the process off without zeroing… it’s likely that normal digital synths do send 0s when oscillators, LFOs, etc. are not in use)

but ya, all that aside, i think the poly~ capabilities demonstrated in the Max5/examples/synths/FMSynth/X.FM~.maxpat example are pretty good. wondering what others think of it… criticisms, likes, dislikes?

32 input. I just mean most synths come with a single input so you’re bound to monophonic if you want a custom oscillator.

As for zeros summing… I’m interested in this to learn. Are you saying that the actual act of summing a bunch of zeros is not CPU intensive or that the SDK has provided a way of bypassing the computation?

@roman,
I’ve rethought this a bit. I think I was wrong about it. I’m working on something that might solve a lot. Easier to just patch and post in a half hour.

it is not that we would need global modulators all the time ^^ but it should be
straightforward, it should even be _easier to do this to poly~ voices compared
to connecting to 32 _different places.

i dont have maxmsp here (my standard excuse not for not creating something
for the forums) but have a look at an older poly~ placebo of mine, i still use it
as a starting point sometimes.

like poly~s should be, this model is strictly DSP. the "targeting" must also been
done completely outside.
on/off is controlled by the main envelope, but it could be anything, including
something from outside.

you will notice that any modulation attempts to the input frequency (as seen in
patch version 10) suggests the use of signal [mtof~] (which is a thirdparty object
for max v4) instead of [mtof], but the effort is minimal.

Attachments:

what you are doing there is where i was suggesting the use of sub-poly~s for.

it is much easier to just have different modulators as a subpatcher in every instance
and let them turn and off according to the user input, so that an LFO of speed 0
and/or modulation amount of 0 will just tunr off and dont process.

this will also result in a 0 signal (in order to multiply and add it with other modulation inputs)

Attachments:

a global modulator at signal rate, of course, can not only find its way to the active
among the 32 voices via receive~., it could also come in via inlet.

and you would not need to to encapsulate the receive~objects in your
synth voices in a sub-poly because you would just turn the whole
modulator off, for example by having it in a _parallel poly patcher.
that will result in an "inactive" signal connection going to each of the
32 poly voices, and that is enough.

Since you have decided to get down to it, I wonder if it would be good to open a new thread and call it MaxMsp native synth part to:building it
This way new people interested do not have to read through 60 messages.

new thread sounds great! wow, this one moved fast while i was sleeping… haha.
just to answer a question that was asked by audiomatt,
"the actual act of summing a bunch of zeros is not CPU intensive"?
yes, the actual act of passing and summing a bunch of zeros is not CPU intensive(when writing externals, you often create an option to 0 the signal when some sort of initialization fails(example, if buffer~-using objects don’t find a valid buffer~ they are told to skip through regular perform method to output only 0, it’s better than possible DC offset and doesn’t cost much))…