Max/Msp native synth

    Aug 29 2010 | 11:37 am
    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....

    • Aug 29 2010 | 1:10 pm
      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.
    • Aug 29 2010 | 3:25 pm
      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.
      • Wavetable synthesis (Single, Double, FM, Ringmod, Fractalize, Sync Granular): The Oscillator produces signals based on monocyclic Waveforms.
      • Sampling (Sample, Granular): The Oscillator produces signals based on a sample.
      • External audio signal (Audio In): The Oscillator delivers an audio signal, which itself comes from an external source.
      • The filter types LPF 2 Pole, LPF 4 Pole, LPF 8 Pole, Allpass 2, Allpass 4, Allpass 8 and Supercomb have an additional FB panel controlling the new feedback loop introduced in ABSYNTH 5 for these filters.
      • Freq Shift or the Ringmod modulation
      • Waveshaper module
      • Effects
      • Draw Waveforms & Spectral Edit
      • Envelopes & Automation
      Absynth is a lot of synth. It would be good if I could just pop an Oscillator abstraction into my project and it came with all the functionality.
    • Aug 29 2010 | 4:13 pm
      I wanted to say to AudioMatt that I use a patch with several VST objects running Absynth and even an ARP 2600 and only when I get really polyphonic it drives the cpu up to 100%.
      Thank you grizzle for this analysis of the Absynth. That's what it is! I thought of Jamona too. Maybe Timothy could give an overview of what it would take under Jamona to get it started?
    • Aug 29 2010 | 4:24 pm
      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:
      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!
    • Aug 29 2010 | 4:55 pm
      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.
    • Aug 29 2010 | 5:01 pm
      "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 ;)
    • Aug 29 2010 | 5:16 pm
      Please... don't call me sir, it's Matt. *handshake*
      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.
    • Aug 29 2010 | 5:19 pm
      ok... I see your edit now. Obviously you're even more angry than I thought. have a nice day. I'll be back when things settle down.
    • Aug 29 2010 | 5:24 pm
      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 ;).
    • Aug 29 2010 | 7:40 pm
      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%...
    • Aug 29 2010 | 8:16 pm
      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.)
    • Aug 29 2010 | 8:40 pm
      not for the fun with argueing, but i feel like replying to this:
      "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.
    • Aug 29 2010 | 8:51 pm
      "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!
    • Aug 29 2010 | 9:10 pm
      Godwin is watching, guys
    • Aug 29 2010 | 9:18 pm
      Godwin's law: "As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches 1."
      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...)
    • Aug 29 2010 | 10:07 pm
      easily spooked?....guilty
      but recently, when i notice Noob4Life has contributed to a thread I think
      "uh oh, this is either gonna be vital.....or confrontational"
      and that's a compliment btw
      and yes, this is a very watchable thread
    • Aug 29 2010 | 10:15 pm
      "uh oh, this is either gonna be vital.....or confrontational"
      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...
    • Aug 30 2010 | 3:25 am
      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.
      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!
    • Aug 30 2010 | 8:39 am
      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 "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.
    • Aug 30 2010 | 9:05 am
      Thank you everyone for pushing this subject forward.
      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?
    • Aug 30 2010 | 10:14 am
      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.
    • Aug 30 2010 | 1:40 pm
      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.
    • Aug 30 2010 | 2:36 pm
      Thanks for your post mesa. What attracts me is the architecture. If you do not know it, please download a demo and click on 'patch'. Only that page is what I am refering to at this point. The data base stuff is a different story. Only the DSP part.
      here is the link
      Max has all it takes. See grizzle's post up here, it consists only of three modules.
    • Aug 30 2010 | 3:38 pm
      just do it!
    • Aug 30 2010 | 4:08 pm
      thanks for the link. but it's 600+MB, so i don't think i can install this on my computer.
      (my c drive is only 2GB and i have some softwares installed already...)
      but i checked out some videos. i know videos tell a small portion of the full functions but i think i got the basic idea.
      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.
      i have built a few drone generators in the past.
      if you compare to absynth, yes they look and sound like garbage but they are very roughly in the same category of the sound and if you look inside there are combfilters and delays that might be useful to you hopefully...
      you may need this to run...
    • Aug 30 2010 | 6:43 pm
      "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.
    • Aug 30 2010 | 6:54 pm
      I find synths interesting, I've shared some ideas in the past and like most of us here I get quite exited when one of these threads pops up. How about we get started on a community project?
    • Aug 30 2010 | 6:57 pm
      (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 ;)
    • Aug 30 2010 | 7:32 pm
      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.
    • Aug 30 2010 | 7:34 pm
      "How about we get started on a community project?"
      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.
    • Aug 30 2010 | 7:50 pm
      Lets go!
    • Aug 30 2010 | 7:55 pm
      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.
    • Aug 30 2010 | 7:57 pm
      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...
    • Aug 30 2010 | 8:12 pm
      poly~ allows to add a patch in the dsp chain without interrupting audio - and, of course, you can use it to disable unused parts of your audio chain and to over/undersample your oscillators
      Very curious about this synthesis thread... looking forward to see what comes out!
    • Aug 30 2010 | 8:25 pm
      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.
    • Aug 30 2010 | 8:28 pm
      "send and receive don't work in it..."
      i must be misunderstanding you... i've been able to use send and receive within poly~(dynamically changing their names using thispoly and sprintf from within the poly~), how have you had problems?
    • Aug 30 2010 | 8:29 pm
      I left off the tildes. sorry.
    • Aug 30 2010 | 8:33 pm
      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.
    • Aug 30 2010 | 8:36 pm
      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.
    • Aug 30 2010 | 8:53 pm
      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)...
    • Aug 30 2010 | 8:55 pm
      If you use [forward] instead of [send] you can set the target dynamically.
    • Aug 30 2010 | 8:58 pm
      "If you use [forward]..."
      yea, exactly, forgot to mention that as i learned recently in another thread from you. Thanks again!
      i posted another example to my previous post(just download #1, as it uses receive~ in the outer patch to show the send~ routes properly... can't find how to delete old attachments...).
    • Aug 30 2010 | 9:01 pm
      Hi There,
      Just a quick input concerning Jamoma.
      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 :
      IMO this would be interesting to see how Jamoma comes useful for such a project so feel free to ask more info in the user list :
    • Aug 30 2010 | 9:18 pm
      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.
    • Aug 30 2010 | 9:35 pm
      "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...
    • Aug 30 2010 | 9:51 pm
      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!
    • Aug 30 2010 | 10:08 pm
      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...)
    • Aug 30 2010 | 10:24 pm
      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.
    • Aug 30 2010 | 10:41 pm
      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.
    • Aug 30 2010 | 11:01 pm
      "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. :) )
    • Aug 31 2010 | 6:48 am
      been studying up and wonder about the specifications we might go 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 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:
    • Aug 31 2010 | 7:02 am
      i dont get this.
      "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.
      the basic structure of an absyth voice is kinda classic i would say, most synths work like that.
    • Aug 31 2010 | 7:14 am
      ("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?
    • Aug 31 2010 | 7:49 am
      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?
      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.
    • Aug 31 2010 | 8:27 am
      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.
    • Aug 31 2010 | 8:42 am
      What if you were to just shove a matrix~, modifiers, and scaling in a poly~ object, downsample it 32 times. Then the outputs of the poly~ would correspond to the destinations in the algorithm.
      Would look awful but it might work.
    • Aug 31 2010 | 8:44 am
      Roman I've been looking for your objects forever where the hell are they? :-)
    • Aug 31 2010 | 8:51 am
      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)
      [poly~ main-poly
      poly~ LFO1, poly~ LFO2
      *~   (
      modulate something.
    • Aug 31 2010 | 8:55 am
      you should not need them to get the idea of the construct.
      i am sorry i am still dont hosting them anywhere. it is on my to do list.
      btw, downsampling /32 is close at the border where you could as well use messages.
    • Aug 31 2010 | 9:18 am
      let me add one more thing.
      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.
    • Aug 31 2010 | 12:44 pm
      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.
    • Aug 31 2010 | 1:06 pm
      @ Hans
      I suggested this halfway through the thread, when it became apparent that the topic had taken on its own life - no response, but it seems some contributors have already begun the process
    • Aug 31 2010 | 1:20 pm
      Everyone coming here to bring ideas, please note that a new thread is open for the continuation of this project.
      It is called: Max/Msp native synth PartII: building it
    • Aug 31 2010 | 2:15 pm
      platzverweis? dann will ich jetzt sofort ihren dienstausweis sehen.
    • Aug 31 2010 | 2:18 pm
      Don't take it too hard. It will help others in the long run. You can object to it though....
    • Aug 31 2010 | 5:58 pm
      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))...
      anyways, onward to thread part deux!
    • Aug 31 2010 | 6:43 pm
      und wem?