djlbe

sorry if that's stupid, i've searched everywhere but

I'm trying to do a poly~ using jitter where each voice are added together, I can't find how to combine them. it's seems one voice replace one other and that's all. don't really understand how it works cause jitter is new for me

sorry if that's stupid, i've searched everywhere but 

q-about-poly-and-jitter

Poly~ was not design for that... Was design to manage voices and lower the CPU usage.

somewhere, deeply in my mind i was knowing it /_

I'd disagree; it's probably possible, just not simple... (though I'm not a jitter wizard, but the tricky part is probably in recombining them, though that seems like a matter of repeatedly writing to a region of a particular matrix)

cool peter that's a good new, even i'm thinking to doing it with gl now. but it should be realy intersting to find a solution for doing this, my knowledge of jitter is too limited for the moment

what would be the benefits over using abstractions ?

interested by poly~ with jitter stuff
what would be the benefits over using abstractions  ?


Dynamic switching of patchers without the need to reconnect patch cords is the first thing that springs to mind, though you also get multiple copies for free, too, so it's a good way of representing parallel processes/data structures. It would probably work particularly well for what you're looking for, Julien, as each voice could represent a different celestial body.

Dynamic switching of patchers without the need to reconnect patch cords is the first thing that springs to mind, though you also get multiple copies for free, too, so it's a good way of representing parallel processes/data structures.  It would probably work particularly well for what you're looking for, Julien, as each voice could represent a different celestial body.


My abstractions system would work without any patch cords to and from them. Only s & r

 Not sure it would be the most efficient but afaik cord = s+r on a performance point of view (not really true in M4L btw)

As written in the other thread, it would cost a lot of time to test both solution, even at a more advanced step of the project

Hi Peter from here too :)
My abstractions system would work without any patch cords to and from them. Only s & r
I wrote would Not sure it would be the most efficient but afaik cord = s+r on a performance point of view (not really true in M4L btw)

That's good news, but according to another post, s&r don't work with poly~ in 6.0.5. Which version are you on? Should I backgrade, do you think?

Seems to work ok here. With that said, I've never found it advantageous to use s&r to communicate to poly~ internals.

Well that's a historical problem with user-drive bug reporting. One never knows if there's a bug in the bug report )

Is it possible to put jit.pwindow, or any other display elements, in a poly module?

Q about poly~ and jitter~