From the original SynthMaker forum (2004–2014), with its members’ names and dates.
mwvdlee ·
As a result of this topic: Is poly processed in batches?
I'd _REALLY_ like to have a white memory write module next to the blue ones. The reason being that you can't separate out white poly's when there are more than 4 active. Perhaps include an extra "write enable" boolean input so writing only happens when that boolean is true, saving performance?
Alternatively, and reasonable way of sharing data amongst poly's would be appreciated greatly. Perhaps something like "shared float myArray[1234];" or so in code? Heck, even a single byte of shared memory would be nice.
MichaelBenjamin ·
that would require the white array to stay in memory and whole rework of the principle the white streams work (spawning/vanishing). i would also like this but maybe it can be done with a more flexible (hopped? 4poly?) blue write module and a primitive that distributes that to the white channels (a non hacked reverse combiner).
mwvdlee ·
MichaelBenjamin wrote: that would require the white array to stay in memory and whole rework of the principle the white streams work (spawning/vanishing). i would also like this but maybe it can be done with a more flexible (hopped? 4poly?) blue write module and a primitive that distributes that to the white channels (a non hacked reverse combiner).
The trouble with blue is that, when more than 4 channels are used, channels are added together. Although it can still be usefull, the number of scenario's is severely limited.
Besides, I'm talking about a memory writer. The memory stays in memory anyway. Basically the reverse of the current memory reader, where memory is shared too. How difficult could it be to hack the current memory reader to do writes instead?
MichaelBenjamin ·
you are right, it gets problematic when over 4 poly.. so i dont know, but i agree that would be very nice if it could work that way.
exonerate ·
Yes I'd like to see this also. I think the best solution would be to give the current wave write the generic dark grey connectors and make it work with any stream type.
Cheers 😉
Exo
mwvdlee ·
Turns out this is pretty much a show-stopper for my main S|M project.
Without the ability to share memory between poly's, I can't finish it as I don't think there is any workaround for it.
So Malc... please consider adding this feature soon, so I can continue work. Pretty, pretty please 🙂 Preferably in 1.1.7 Beta7 or something like that? 😉
mwvdlee ·
Alternatively, if "memin" was supported for both read and write in the Assembler module, we'd have shared memory too and would write our own "Poly Memory Write" modules. Actually, r+w memin support would be better than merely a "Poly memory write" module.
oddson ·
mwvdlee wrote: ...[a] reasonable way of sharing data amongst poly's would be appreciated greatly. Perhaps something like "shared float myArray[1234];" or so in code? Heck, even a single byte of shared memory would be nice.
What about the Edwin Cafe trick in the Mono2Poly module? Doesn't that allow some sharing? I'm not sure if that's what you mean but not everyone knows about that module so I thought I'd ask.
If OutSim would finish the 'Voice Tag' output from the V2P primitive this would go along way towards a lot of the suggestions on the limitations of Poly mode.
mwvdlee ·
oddson wrote:
mwvdlee wrote: ...[a] reasonable way of sharing data amongst poly's would be appreciated greatly. Perhaps something like "shared float myArray[1234];" or so in code? Heck, even a single byte of shared memory would be nice.
What about the Edwin Cafe trick in the Mono2Poly module? Doesn't that allow some sharing? I'm not sure if that's what you mean but not everyone knows about that module so I thought I'd ask.
If OutSim would finish the 'Voice Tag' output from the V2P primitive this would go along way towards a lot of the suggestions on the limitations of Poly mode.
The Mono2Poly also uses memory for the trick, pretty much the same way I do. It also has the same problem that any changes made to the array are only available to the other poly's after a significant and noticable delay, making it useless for anything DSP.
p.s. If we had shared memory, we could possibly create our own Voice Tag module 🙂
MegaHurtz ·
I think it`s easyer to dynamicly allocate lines of code than it is to allocate chunks of memory.
Especcially becouse one would expect the content to remain in memory. So it`s not a reformatted copy.
But a unique instance. I suspect the question is how big can you go, where in this case the amount of memory
would be bound to the number of voices.
mwvdlee ·
MegaHurtz wrote: I think it`s easyer to dynamicly allocate lines of code than it is to allocate chunks of memory.
Especcially becouse one would expect the content to remain in memory. So it`s not a reformatted copy.
But a unique instance. I suspect the question is how big can you go, where in this case the amount of memory
would be bound to the number of voices.
I suspect your reply should've been in another topic, it doesn't seem to have anything to do with this one 😉
MegaHurtz ·
It does but maybe it`s a bit illusive 😉
mwvdlee ·
MegaHurtz wrote: It does but maybe it`s a bit illusive 😉
Perhaps if you could explain what dynamically allocating lines of code, amounts of memory and number of voices has to do with being able to use memin in Assembler module or having a Poly Memory Write module?
MegaHurtz ·
for poly to be more efficient you dont need a full storage of everything.
Since you know the code that gets executed is the same as the ones before.
And you yust do it some more at the point you need more.
But if you want to store something in memory the thing you stored is different per voice.
So you have to have an array size of "voices*arraysize" by default.
It`s really a memory hungry thing. Perhaps you are better off with manual control over this.
mwvdlee ·
MegaHurtz wrote: for poly to be more efficient you dont need a full storage of everything.
Since you know the code that gets executed is the same as the ones before.
And you yust do it some more at the point you need more.
But if you want to store something in memory the thing you stored is different per voice.
So you have to have an array size of "voices*arraysize" by default.
It`s really a memory hungry thing. Perhaps you are better off with manual control over this.
This has nothing to do with efficiency.
This has nothing to do with control over memory allocation.
If I wanted to store things in memory that were different for each voice, I wouldn't need shared memory.
All I want is for poly's to be able to read & write, in real time, to a shared memory.
All I want is to be able to read & write to memin in the Assembler module.
I don't see how any of your points have anything to do with this request.
I really, really, really think you are talking about this topic: [old link]
MegaHurtz ·
Oh man +1 for the memin as I was pondering upon the alternatives months ago.
But effectively what yr saying with "white memory" is poly memory.
I see what you did becouse i did it in code before.
This reply was a merely disadvantage of poly memory.
Ill have a reply to this in a constructive matter on the beta`s section.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker