Poly as data path
-
UrbanCyborg
- Posts: 599
- Joined: Mon Nov 15, 2021 9:23 pm
Poly as data path
Is there some way to use a poly jack as a data port for generic data that doesn't fall foul of the master poly voice count?
Cyberwerks Heavy Industries -- viewforum.php?f=76
Re: Poly as data path
Yes and no.
Yes, in that Adroit Synthesis S-Poly connections do this in LSSP.
https://www.adroitsynthesis.com/s-poly-connections/
No, in that it's not possible to do it using Cherry Audio's basic technology.
It's a long story.
Yes, in that Adroit Synthesis S-Poly connections do this in LSSP.
https://www.adroitsynthesis.com/s-poly-connections/
No, in that it's not possible to do it using Cherry Audio's basic technology.
It's a long story.
-
UrbanCyborg
- Posts: 599
- Joined: Mon Nov 15, 2021 9:23 pm
Re: Poly as data path
Yeah, I knew you had a special jack, but didn't know how it worked. Reading the link you posted, I think I get the drift. Seems to me, though, that CA should have allowed for some means of patching raw data between modules. I think that should be a feature request, don't you?
Cyberwerks Heavy Industries -- viewforum.php?f=76
Re: Poly as data path
Indeed.
When I discovered that CA had crippled the Poly functionality by "cutting the wires" I wrote them an impassioned plea to make a simple modification.
To no avail.
So I had to invest intensive effort developing a very tricky system-level bypass in order to implement S-Poly.
In principle I'm willing to license this technology for free to other developers but would prefer you to badger CA so that they eventually see sense.
When I discovered that CA had crippled the Poly functionality by "cutting the wires" I wrote them an impassioned plea to make a simple modification.
To no avail.
So I had to invest intensive effort developing a very tricky system-level bypass in order to implement S-Poly.
In principle I'm willing to license this technology for free to other developers but would prefer you to badger CA so that they eventually see sense.
-
UrbanCyborg
- Posts: 599
- Joined: Mon Nov 15, 2021 9:23 pm
-
collidermod
- Posts: 31
- Joined: Mon Mar 08, 2021 12:28 am
- Contact:
Re: Poly as data path
I had a similar discovery and reaction. With GN64 I had experimented with solving this problem too by creating a binary protocol and bit packing data packet into a single Java double. The problem ends up being that jacks are only one way.
If we're just talking data, MIDI is an option here too. The protocol is generic enough I'm sure you could fit your own system exclusive messages.
One last idea, if the "data" being passed is more in the config/settings space, and you want this communication to happen more as a convenience for the user, rather than a substitution for patching, there also is `GetManufacturerProperty` and `SetManufacturerProperty`. I haven't messed with these much, but I get the impression they can be used to share config data amongst modules.
Re: Poly as data path
I use bit packing in some applications but there are only 64 bits available so if you want 16 channels at sample rate you're down to 4 bits per channel which is pretty useless.
CA MIDI support is limited to just ShortMessage data so I didn't go down that route.
Get/set property methods simply read and write XML files so there are obvious bandwidth problems with that approach.
I decided that shared memory was the way to go. But although it's simple in principle getting it to work in practice was quite tricky.
At the moment S-Poly is just 16 channels of 64 bit data at sample rate in one direction but I've thought about bi-directional transfers. As shared memory is used there's nothing stopping bi-directional transfers. Indeed connections could be generalized to the point where any Java object might be shared between modules, so for instance it would be possible to transfer bulk data like large samples or even video if one wanted to expand VM into the visual synthesis arena.
CA MIDI support is limited to just ShortMessage data so I didn't go down that route.
Get/set property methods simply read and write XML files so there are obvious bandwidth problems with that approach.
I decided that shared memory was the way to go. But although it's simple in principle getting it to work in practice was quite tricky.
At the moment S-Poly is just 16 channels of 64 bit data at sample rate in one direction but I've thought about bi-directional transfers. As shared memory is used there's nothing stopping bi-directional transfers. Indeed connections could be generalized to the point where any Java object might be shared between modules, so for instance it would be possible to transfer bulk data like large samples or even video if one wanted to expand VM into the visual synthesis arena.