hi,
i need to create a lot of instances (let's say 3000) of a gem
abstraction. each instance has to hold it's own variables, so it is
difficult to work with repeat.
In the past I always used pd-messages to create these objects, but I
have the feeling that it would be faster and easier to do in a
Sounds like a good time for [nqpoly4]. I have used it to manage 1000
instances of one abstraction and more than that for multiple
abstractions. Check the included Gem example for nqpoly4.
.hc
On Apr 10, 2008, at 12:10 PM, marius schebella wrote:
> hi,
> i need to create a lot of instances
marius schebella wrote:
> are there any plans to support scripting of pd objects (in this case gem
> objects) within lua or any other scripting language?
Support already exists to the same level that it does in Pd.
You can use pd.send(name, sel, atoms) to send to subpatch's receiver. (I
think,
well, nqpoly4 asks for a very special method to write your abstraction,
and I wonder if there is an overhead from additional send/receives?
besides, I will try it, never used it before, thanks.
marius.
Hans-Christoph Steiner wrote:
>
> Sounds like a good time for [nqpoly4]. I have used it to ma
Hallo,
marius schebella hat gesagt: // marius schebella wrote:
> well, nqpoly4 asks for a very special method to write your abstraction,
That's only because it's a generic helper for dynamic patching. You
could of course also just do your dynamic patching the traditional
way.
> and I wonder if
Hi Marius,
i've used py and dyn~ in combination for such stuff many times.
With that many objects it makes probably sense to put the
abstractions in subpatches (e.g. 30 subpatches with 100 objects each)
as pd has problems with many objects in one canvas.
gr~~~
Am 10.04.2008 um 18:10 schrieb ma
thanks for all the answers, I guess I am really looking for something
like actionscript for pd, based on lua or python. I understand that all
of the suggested solutions are working, but all have some minor
downsides, or overheads (of coding) or dynamic restrictions.
marius.
Thomas Grill wrote:
hi marius
sorry to switch in so late, but let me mention another approach. if you
only have numeric arguments for your abstractions, you could
alternatively still use [repeat] and read the different values from
a/several table/s. that is what i usually do, when i need - let's say -
1000 cuboids at
I tried that too, with a set of new patches and it was quite fast
(although I think not as fast as luagl), but I already have a lot of old
interactive object patches that I wanted to use. they have mouseover
handling and also store textinformation.
actually it is a question of performance. I wan
In GEM if you need lots of objects then try to avoid using a gemhead or
separator for each. The setup time for pushing and popping the matrix
thousands of times starts to add up.
Also, use a model so rather than compute and upload the geometry in
immediate mode each frame a display list is called
chris clepper wrote:
> In GEM if you need lots of objects then try to avoid using a gemhead or
> separator for each. The setup time for pushing and popping the matrix
> thousands of times starts to add up.
I don't know how I could translate the objects correctly without
gemheads or separators
On Fri, Apr 11, 2008 at 11:43 AM, marius schebella <
[EMAIL PROTECTED]> wrote:
>
> I don't know how I could translate the objects correctly without gemheads
> or separators, maybe storing the current XYZlocation and subtracting it from
> the relative position? would that be faster than to use push
Hallo,
chris clepper hat gesagt: // chris clepper wrote:
> C++ - Jamie did a lot of this for his personal use.
>
> I have not used luagl, but I suspect it will not be comparable to C in
> speed.
luagl is not as fast as C, but it's already much faster than using
lots of separators or double gemhe
hello,
Frank Barknecht a écrit :
Hallo,
chris clepper hat gesagt: // chris clepper wrote:
C++ - Jamie did a lot of this for his personal use.
I have not used luagl, but I suspect it will not be comparable to C in
speed.
luagl is not as fast as C, but it's already much faster than using
lots
Hallo,
cyrille henry hat gesagt: // cyrille henry wrote:
> >luagl is not as fast as C, but it's already much faster than using
> >lots of separators or double gemheads.
> >
> >Regarding Gem-externals: Does anyone have a simple template project
> >how to write and compile a custom Gem external? Th
hello frank,
not sure how to compare. the lua code fades the lines out, but the c++
object does not. I can create 10 lines in lbuff and still only get
34% cpu use. with lua and aging 0 I can only have about 17000 lines.
marius.
Frank Barknecht wrote:
> Hallo,
> cyrille henry hat gesagt: // c
16 matches
Mail list logo
