Forums > Gen

Gen~ in Poly~ take a long time to load

August 4, 2012 | 11:05 am

I’m wondering why poly~ with a lot of voices and gen~ inside poly’s patch take so long to load ?
maybe each gen is compiled individually ?

Ben++


August 6, 2012 | 12:45 pm

Exactly. It’s possible in the future that this can be avoided, but not currently, unfortunately. It’s been logged as a feature request.


August 6, 2012 | 1:20 pm

What about Gen~s that are referencing saved .gendsp files? Does it still compile those at each load of the poly~, or are they pre-compiled when saving?


August 7, 2012 | 8:03 am

Still re-compiled when loaded, unfortunately. It’s on the feature request list.


August 7, 2012 | 8:07 am

Noted! Thanks for the info. I doubt you’ll be able to answer the next question, but there’s at least one thing (and then also this) I’m looking forward to in a future release. Any idea of a timeframe for the next point release? It’s been a while since the last update.


December 26, 2013 | 1:46 pm

Hi guys ? it is still on a list or has been rejected for a while ?
When it comes to M4L with poly (& multiple instances of a device) , i can go shopping while its opening . its not for real life scenario . This way Gen is suitable only for special/unique cases . i cant use it


December 27, 2013 | 3:13 am

in the meanwhile, i would suggest, in the case you have a finished gen subpatcher, writing a proper c max external with the gen export tools… surely this is possible ?


December 27, 2013 | 12:14 pm

that would be a miracle . i really dont want to learn C dsp to take difficulty of making simple things performing faster , i want to live . management and setting up environment for coding AND coding itself its always about problems and constant improvements , never finished projects due to time that has to be concerned and effort (i havent been born as a geek) :/ with Gen i can do things with less brain effort , faster , debug , have fun , have family .
i would love to be able to take my knowledge and build tools for frequent and everyday use , things that i need at particular time , things that can be used more than ONCE within a project/composition .
But loading Gen more than in one device its a nightmare due to "never ending" compilation (with poly – to infinity ). Exporting Gen to "max external" would be a miracle , the biggest step in history i dare to say.

C74 ? Fathers ! please , its few years since this talk . you can always say no . it just would be great to know if any of these requests will be taken under consideration . i would also like to prepare myself for a change or not .


December 27, 2013 | 12:36 pm

i really understand your point ! i was merely pointing that, when it comes to writing/compiling a useful msp external, beginning with a gen patcher is supposed to be one of the simplest and most straightforward route. Still far from ideal, and if you have no clue about c/c++ programming and compiling, it’s still a big learning gap, i can only agree. Not to mention that compiling a msp external from an exported gen code seems like a step backward…


December 27, 2013 | 12:56 pm

yes sure Vichug .
i think Gen can suit my quasi-geek needs , i truly love it (even if its not ideal),it changes the way im thinkin and prototyping – i prefere to code but not the way C has to offer . im not blaming C developers im just not that capable to learn it to make it useful for my needs – so this is less ideal scenario . its just too much . C need a special attitude , and MAX gave me an option to be myself in some way . it would be great to still have this comfort . do better things in this environment .


March 6, 2014 | 2:40 pm

Hey !
I am currently facing that sort of problem !… a granulator in gen~, in a poly~, 64 voices, incredibly long to fire… and i would prefer not to have to export the code and writing a c external out of it, indeed… sooo, the sole purpose of this unburying is to know if there is any advancement on that topic – ie, beeing able to "embed a compiled gen~ in patcher" or "one-gen~-compile-is-enough-for-each-poly’s-voices" ! any advancement on that topic ?


March 6, 2014 | 4:05 pm

Yes. I can’t make any promises about when this kind of thing will be released, but it is a development priority.


March 6, 2014 | 4:08 pm

Cool ! good to know, thanks


March 6, 2014 | 6:24 pm

+1 for "gen~ within poly~" improvement.


March 15, 2014 | 9:55 am

Hi ,
it took quite long to receive any information if such issue is under consideration . I had to decide what to with it on my own .
I took C external development approach , i had no choice .
As a result ive got less time for living life but much more efficiency within Max . I cant conclude if this is better scenario or not ,just yet .


June 2, 2014 | 3:24 am

+1 for "gen~ within poly~" improvement.


June 2, 2014 | 5:26 pm

As a result ive got less time for living life but much more efficiency within Max . I cant conclude if this is better scenario or not ,just yet.

You did the right thing. In the long run you will have more time for living because the efficiency of the solutions and the extension of your mind will make you think of the math faster than ever(even right there back in stupid-simple Max :D).

There is a C++ workflow for Max externals, too, (can’t remember…maybe Tim Place had something on it on his site?) and it’s likely the export of gen~ to an external could be more direct that way…. dunno… might be something to look into.
But when i started writing MSP externals in C, the capacity to experiment with so much more at the same time(due to the efficiency gain), opened up worlds… if you think of time in terms of CPU-cycles you’re saving, and your computer as part of the space within which your mind is allowed to roam and really live, then YES! you already have more time for living some kind of ‘life’ ;D

Yes. I can’t make any promises about when this kind of thing will be released, but it is a development priority.

I’ve got a hundred voices spread out in different poly~s within one app i’m building… i notice the smaller the number of voices in a poly~, the (slightly) less time it takes to load(instead of a 64-voice poly~, i spread it out into 4 16-voice poly~s and despite gen~ inside of them, load time seemed slightly less… instead of 30secs it’s now 25 :p).
And also, despite the fact that the apps i’m building each take around 20-30secs to load, i’ve still had time to build about three of them with so much gen~ involved in just a month. Finally, once they load, gen~ brings so much FIRE!
So i guess all i’m saying is…and not that it should be any of cycling74′s concern whatever i say here…but…:
take however much time it takes to do it right, i’m still so impressed with gen~! :)
(i still think i should keep going back to supercollider, but i’ll do that after i figure out more about exporting gen~ code for sc ugens :D)


June 3, 2014 | 1:33 pm

:) thank you Raja for encouragement . Ive already noticed benefits , after that time im feeling joyful and somehow thankful that such issue could lead me to fantastic results ,where imagination is my only limit .
Im not a geek but procedural "thinking" is one of the best things ive learned so far , which helped me to jump into C development with hope and joy actually .

Well it wasnt too easy i must say .
And the fact that i come from JS wasnt sensitizing me on different coding habits as C and C++ are strict/strongly typed languages ,and all that memory management (damn).
I had to understand why its important before blaming it ,but somehow i stated to truly love it .
Thanks to Cycling guys .

Ive gained better understanding and experience of max environment though the API crawling ,it taught me to be much more concern about certain things and become more aware of data flow and dependencies which is very important in my projects so far .

The downside of it all is that im less patching and more coding , it reflects when i want to help someone . I can pick things that are more suitable for coding scenario than patching itself , sometimes it is not what someone could expect with my help .
Constant : learning .


Viewing 18 posts - 1 through 18 (of 18 total)