Discussion:
UGen like TGrains but without amplitude envelope
Hanns Holger Rutz
2014-10-08 13:02:13 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,

is anyone aware of a UGen - perhaps from a third party plugin - that
is similar to TGrains but without enforcing the hanning amplitude on
top (perhaps no envelope or a custom provided envelope)? perhaps even
capable of processing multi-channel input buffers?

thanks, .h.h.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUNTXRAAoJEKZFmaPaYk6QXuIP/jFJXmg5P/eLticwQPbUdi+L
pEMeipT/mwAUzEKjtJaT8KKqMGnqedUcNODoRrnMSzHhyZoqG6yu+6VKoQ2gx7iq
RCoun9vhGXIjW8WPpcmR+rU5dgP9Jb1V87eF5Q4zGKfNm1FTce43bhMiLfQjG5e+
52xmsaDCq77c7L5w3TCW2yq0oExqhKfsrBNEpm8fIEAMEn8kahR2v6wKaJDmW/BE
1TR7ERwFObXJUnqmwbz3OeXineGjtxSFHu7vaXDq+0FDEaV+N77IfCUVsvtYWBwR
x1513LO9hxjX7RzOmC0nb2sUIMpqUKebzc/nbSFL4nXw8nPi1Lbi0ltZ+NdM93+I
mIPGNiNXA+2yMwr5C7Q6/7TmRILQRh/3Meh4/3Z6X96wkrWDFKCSAknb/yk1hin+
2aOE2Z+enWU7FCdI+5InRxiVeoqVbv7/YG95TnEpvQ0VaEkviW7vavAR+YBFptVN
vcQN3ya6PAjrwXHcZBZp74G/0sc7rjU0JhdacgZF6RvZujkS4+4faQJ1jmLxaIJk
HvXfgk2/zWdXRl673U/ONn3gHUFEfsPbN8EEaRCPx00+AJovJNEl7KnzV1q7cB6d
++F/z+XMWH9xQvndmyiOmpk4Onb5LSBuiCw3XiiKcKpVlbcEysMwp9cZLlQGDoeY
RKiEeE/kw76QkejB3/1k
=+FF/
-----END PGP SIGNATURE-----

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Hanns Holger Rutz
2014-10-08 13:10:06 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Perhaps TGrains2 from BhopUGens:

https://github.com/supercollider/sc3-plugins/blob/master/source/BhobUGens/sc/HelpSource/Classes/TGrains2.schelp

(could use zero attack and release time I guess)

Does anyone know how TGrains and TGrains2 handle polyphony - is that
dynamically allocated and unlimited, or is there an internal max
number of voices?

If I have an SC install via my package-manager (Debian > apt), what is
the process of installing the BhopUGen plugins? Do I have to compile
them from source? Any links to a step-by-step guide?

Thanks!
Post by Hanns Holger Rutz
hi,
is anyone aware of a UGen - perhaps from a third party plugin -
that is similar to TGrains but without enforcing the hanning
amplitude on top (perhaps no envelope or a custom provided
envelope)? perhaps even capable of processing multi-channel input
buffers?
thanks, .h.h.
_______________________________________________ sc-users mailing
list
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
http://www.listarc.bham.ac.uk/lists/sc-users/search/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUNTeuAAoJEKZFmaPaYk6QrPIP/3Tp0TjgH7QqmDIXkB6m1tno
/sP25Z71Ga7N9tDXmujXej11znMIPr034IL58Wo+e8rNSZQiqDIk0pYv7WuQeT5r
Azy7OomPcjw4hS6QphE02rgchT6F7XJTDstnHM0kfcPu0jxix7u+UNkPtP9RJLns
RrtDqOnCk3eq4VqIG1QsK5F/FFn4fa6/0ALSYKq+viPR4ffYOfP/AGbH/najQUEq
2Rn4fjfBNYXsWX4keRJEqnlMQn4sDrMXlidR5/CuBKiOVQZ+7RroJA4puWiNnooR
54UX5lcMxhu5B4cOTp7qXSRXs1vr9CE7IytIN5A2k+0pPwSnIGJNOwVwFBYn4POm
4ow5YWR3/AtuqZXLOrU7iJo03JliWhoLPpecfdmASF4qKJe68xs0LLq9212d5VBM
CFNN2pqGnXrhEckvASHh3BpZ0EccvV5lKU7ibI81FuKYzjZa6E6diVuZrx4jR8C/
LbK/NC9EVOjdo3FeyBElVD7AlIUdIg61XRqGtIAi3b8EFGx3dWLiJzYnJMWinBnT
WarbeLQkDyYsdEvR+WXqSCYL2nqRoRkn5dGz6wUDhndqlfLB5KwSXnGExne143WY
LN11qJNB7f5OjcOFXcd6Gx18MrpB9JPtWVdhOtlKKRbDikYm/RUHHsSBYG4VqTYB
V62Md6iCPHfRL1enFbVy
=DAMb
-----END PGP SIGNATURE-----

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
James Harkins
2014-10-08 13:47:40 UTC
Permalink
On Wed, 08 Oct 2014 15:10:06 +0200
Post by Hanns Holger Rutz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
https://github.com/supercollider/sc3-plugins/blob/master/source/BhobUGens/sc/HelpSource/Classes/TGrains2.schelp
(could use zero attack and release time I guess)
I'm not aware of any SC granular UGen that allows multichannel buffers.
TGrains2 is no exception.

GrainBuf and its cousins support a custom envelope, sampled and loaded
into a separate buffer.

Also, the GrainBuf units have a parameter for the maximum number of
simultaneous grains, whose default is 512. I don't know TGrains does it.

hjh




_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Hanns Holger Rutz
2014-10-08 13:51:54 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ha!

so that's the plugins compile error - GrainBuf is already part of
standard SC now. So I think that should be perfect, thanks for the
reminder!

Best, .h.h.
On Wed, 08 Oct 2014 15:10:06 +0200 Hanns Holger Rutz
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
https://github.com/supercollider/sc3-plugins/blob/master/source/BhobUGens/sc/HelpSource/Classes/TGrains2.schelp
(could use zero attack and release time I guess)
I'm not aware of any SC granular UGen that allows multichannel
buffers. TGrains2 is no exception.
GrainBuf and its cousins support a custom envelope, sampled and
loaded into a separate buffer.
Also, the GrainBuf units have a parameter for the maximum number
of simultaneous grains, whose default is 512. I don't know TGrains
does it.
hjh
_______________________________________________ sc-users mailing
list
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
http://www.listarc.bham.ac.uk/lists/sc-users/search/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUNUF6AAoJEKZFmaPaYk6QiCYP/jyGjukAqLGPxpV2HqKA8QI3
YfqymbRkQ5+mlVv7MBhmyRtCovh3hiEu2r3W+djdUm/nXB6I58cIKufk4D1GPswy
HI4lN1kpA3tzuFO8hBUasGDSZQuDRwiqjYqa0Bm6hXYNY86UGoJPvhscCecbOkeP
bhMYVqvvoBNy8jbc2hmNfSsJmGM5z8rZwtjBUS7klkhhaLFX//APUliZwO7voY4Y
hKyEYaRZcVg2mrw60CD29p1CwgJ0m7aeAWRCOtQ/cIAfdkPco5DQMUvIAh8RupOL
bFWbqC4QXyZrBo5uZrBYTHKQAFYmnlGglUeY/l4eUvFKInILaUdI5al1cEEewYpi
84DAyXLTsjdelzkbbKCTaB/a8kt9qpl4EgxQypTZAYuCh8J38hF9Qk2obOEAIweJ
eiNeDO+Py5g41g2eW/3+b7hFJT9FLmgVh7valFVcmdbTy3c+fCjSAr+ro6iOzoOd
pBAE90QAbSo3frAoSrbnFpM2X0pbLV8e3FfOEzDkqIpDFxSCcjAVgokhZbQAX/jf
mKTlvO8Vw3xIQRkvpXlUY/ixmq5/8J93swSYxWrNKFt8Sm/OC8SMYXO05zG1Y4a0
88IBrAXDRAvDQgf/PQ14f8W/Wzsg/C9UsKMiihjgW8I9973mR8otu/G56Kmm79Na
M6fNFTTEaOBybjrEQSma
=gwSN
-----END PGP SIGNATURE-----

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Daniel Mayer
2014-10-08 15:15:40 UTC
Permalink
Post by Hanns Holger Rutz
Does anyone know how TGrains and TGrains2 handle polyphony - is that
dynamically allocated and unlimited, or is there an internal max
number of voices?
Hi Hanns Holger,

in the sense of per-grain parameter control and fx handling
polyphony can be done with TGrains and a multichannel trigger,
but it's rather tricky, Julian suggested this way
(the PulseDivider discussion we had then, also started here)

http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/per-grain-control-of-amplitude-in-GrainFM-td7598072.html

You have to choose channel (i.e. PanAz) params correctly,
a permanent source of confusion as you stated recently.
I've added an example with this strategy to miSCellaneous lib,
Nr. 1e in the Buffer Granulation tutorial.

I'm not aware of combining this trick with multichannel buffers is possible
with any of the granulation ugens mentioned, you'd have to check.

Anyway I think differentiated control of grains ('granular polyphony')
is *much* easier with Patterns, also using multichannel buffers/buffer arrays.

Greetings

Daniel

-----------------------------
www.daniel-mayer.at
-----------------------------

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Hanns Holger Rutz
2014-10-08 15:22:15 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Daniel,

GrainBuf is fine basically. You can easily multi-channel expand that
since the trigger is deterministic.

The problem I'm having now is that polyphony in that case is locked
in. E.g. if I want to feed the result through a resonant filter, there
is no way to control each grain's individual resonance frequency.

The only solution for that (apart from all-client side which is not
feasible in my case) would be to build polyphony from scratch on the
server side. The problem is that scsynth doesn't have a mechanism that
would keep unused voices idle (if I'm not mistaken), so with `Select`
and co you will end up wasting a lot of CPU resources.

Wouldn't it be possible to write a UGen that "wraps" a sub-tree and
turns calculation on and off, similar to how Max' poly~ works? Is
there anything in scsynth that would prevent this from being
implemented? UGens could still run all an init-cycle and then just
pause as if they were "demand-rate", right?

Best, .h.h.
Am 08.10.2014 um 15:10 schrieb Hanns Holger Rutz
Post by Hanns Holger Rutz
Does anyone know how TGrains and TGrains2 handle polyphony - is
that dynamically allocated and unlimited, or is there an internal
max number of voices?
Hi Hanns Holger,
in the sense of per-grain parameter control and fx handling
polyphony can be done with TGrains and a multichannel trigger, but
it's rather tricky, Julian suggested this way (the PulseDivider
discussion we had then, also started here)
http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/per-grain-control-of-amplitude-in-GrainFM-td7598072.html
You have to choose channel (i.e. PanAz) params correctly, a
permanent source of confusion as you stated recently. I've added an
example with this strategy to miSCellaneous lib, Nr. 1e in the
Buffer Granulation tutorial.
I'm not aware of combining this trick with multichannel buffers is
possible with any of the granulation ugens mentioned, you'd have to
check.
Anyway I think differentiated control of grains ('granular
polyphony') is *much* easier with Patterns, also using multichannel
buffers/buffer arrays.
Greetings
Daniel
----------------------------- www.daniel-mayer.at
-----------------------------
_______________________________________________ sc-users mailing
list
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
http://www.listarc.bham.ac.uk/lists/sc-users/search/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUNVanAAoJEKZFmaPaYk6Q07QP/0N2Spbo8jpIHv8JnDJ+uurN
wDd/P31h25HZxUGMs0dBILfqInogTSzdjpi+Ajgbt6BpJjY85dCdxPlYVT56MCOe
O+5/fiYVwxkxTlyyHViNKZ/QLZqTDEGFAKGAs9VVT/Op4/LirruWVGPdJWWUH0mm
ftPJU+Zcm7n7a38SPNiJVk7R5eZgv5cIDZbApBsHQYHOeDMylWWtBavNZJaaBhPL
03JGAsD52bNehy1HtB1G6B8bPDWg3k/12IFNVG0xpFQoL5CxVY5mNTcs2jFtYG6C
xuQrNz5qhzylwqy0NFdkCKpXfMASAet8hJ30zy2PeWJbPx2xWlLMTWRvz/ZDLNbK
H4aACS6Ql419bedoVHqC0+zl+dz9dqQe2W+M959L31n7ogr3AgGkkc+kXu/l+08D
vtAY9pUxt2v7Yz2pXqgOpcFJ+wO0Iowt7m3S9wSdSmXSW1UV+B54O2cd/BbkbIPz
FGxFC7gj5qOhryF3QECTRaAJ0AzF2Mjjco//g5SnpLtZvcl9kH9HczJ26zpCI9zU
Vv5C5DgNQ+chKppSOEl70IqkY73NyzXkaN0r14PToxZvyq3snUL/PXQEuOsoDPP+
NwvMkLMVrojXCTo/oqtHeJnPJUk+BnR7LHqqOrRgAi1KtaN0WQtrr44hi/JeTvRo
XUMzaBFic7JaPzS1XqAq
=XbHe
-----END PGP SIGNATURE-----

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Daniel Mayer
2014-10-08 15:34:30 UTC
Permalink
Post by Hanns Holger Rutz
The problem I'm having now is that polyphony in that case is locked
in. E.g. if I want to feed the result through a resonant filter, there
is no way to control each grain's individual resonance frequency.
It is - as said have a look at Ex. 1e from miSCellaneous lib
which is doing just that, per-grain filter effect -
in short the frequencies must be demanded by the
correctly indexed channel of the multichannel trigger, before mixing.

Greetings

Daniel

----------------------------------------------------
http://daniel-mayer.at/software_en.htm
----------------------------------------------------


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Hanns Holger Rutz
2014-10-08 15:43:13 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 08.10.2014 um 17:22 schrieb Hanns Holger Rutz
Post by Hanns Holger Rutz
The problem I'm having now is that polyphony in that case is
locked in. E.g. if I want to feed the result through a resonant
filter, there is no way to control each grain's individual
resonance frequency.
It is - as said have a look at Ex. 1e from miSCellaneous lib which
is doing just that, per-grain filter effect -
Exactly, you divide the triggers and mix. So you have to be very good
guessing the number of voices you need, and CPU always runs all voices
no matter if you're using them or not. (trigRate varies in my case).

Best, .h.h.
in short the frequencies must be demanded by the correctly indexed
channel of the multichannel trigger, before mixing.
Greetings
Daniel
----------------------------------------------------
http://daniel-mayer.at/software_en.htm
----------------------------------------------------
_______________________________________________ sc-users mailing
list
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
http://www.listarc.bham.ac.uk/lists/sc-users/search/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUNVuQAAoJEKZFmaPaYk6QipsP/2hF3LEkL1BCU0ukcYqWPW4K
93L0N/jiSMZqAZpjojrz7UE9PTOYG4hXK/+srBaRcmqESmPXND7e+bUXj62bJ8sP
g1q8zzzlG7XPGBKqgadj/l9CMuIL4sclNgOSG86Be5BcSATa0t8zkUWnn4cdyKgx
ueNUi0sJYYS51imGhcCrRK0O4i9pFvkf0lx4lxcNPkMMPzNRHDKKGZAkwfEUUh1d
GDdpvNtytTSMTr9ZrTiqeqq0ZvcbzCDpLjy8LLx5H9KQsQcTRn9jQ1INEv3ZlF2K
PORR9+5lazzcAMJmS5MkIY2Mp84CPed3knacHUN8yLiqCoBjQQy6ITMr6gD0I6rq
ij32z392tTp1JlWSBNxOlaXbVw+uFQ/DQ+nVY0IgHkJn0BY/CjK0JoUTrzxNd/st
qT7OtvuA8QGESGPV+4JYvkVAx4oKxqbPVNFKu/sLgX810WC6lkYx9qFDzN+XHytY
nl+zbom5YlCtggPRgRhOW9o5XkcgAcVhyvO6UPeLzirlVGOMeBHmuCTNF9AEuZVf
GDAIg5TgmPPBYAZRmD1cmftr2sAC+vfbMSkk0/O1DKPiZePAoHa56Mh9eVSVvqb7
e5RBeHRLAgEkAkrKwoJXqzKKQjV+tGaPU87wpGjGxs7zCmNy+LZ/3AvvfEgous64
8lJZTgqHp2JotmH20U5V
=Tsuy
-----END PGP SIGNATURE-----

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Daniel Mayer
2014-10-08 19:23:22 UTC
Permalink
Post by Hanns Holger Rutz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 08.10.2014 um 17:22 schrieb Hanns Holger Rutz
Post by Hanns Holger Rutz
The problem I'm having now is that polyphony in that case is
locked in. E.g. if I want to feed the result through a resonant
filter, there is no way to control each grain's individual
resonance frequency.
It is - as said have a look at Ex. 1e from miSCellaneous lib which
is doing just that, per-grain filter effect -
Exactly, you divide the triggers and mix. So you have to be very good
guessing the number of voices you need, and CPU always runs all voices
no matter if you're using them or not. (trigRate varies in my case).
As usual with SynthDefs the maximum channel number is fixed
and you can use less by zeropadding.
'Voices' in this example means the maximum number of overlapping
grains, the 'overlap' param. Haven't tested with TGrains,
but with GrainBuf it's limited to 512 - which should be sufficient
for most use cases.

The mapping to output channels on the other hand
might still be handled in a flexible way, just like triggering
filter frequencies per grain, grouping and routing grain chunks to different
outputs can be triggered dynamically.
I suppose this to become a quite unpleasant index fiddling,
but it might pay (compared to Pbind granulation) if you do CPU-heavy granulations
and could be an interesting possibility for spatialization effects.

Greetings

Daniel

-----------------------------
www.daniel-mayer.at
-----------------------------



_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Josh Parmenter
2014-10-08 19:34:04 UTC
Permalink
Also - in josh ugens in sc3 plugins, there are variants of the basic ugens that allow grain by grain amp control.
Best
Josh

/*
Josh Parmenter
www.realizedsound.net/josh
*/
Post by Daniel Mayer
Post by Hanns Holger Rutz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 08.10.2014 um 17:22 schrieb Hanns Holger Rutz
Post by Hanns Holger Rutz
The problem I'm having now is that polyphony in that case is
locked in. E.g. if I want to feed the result through a resonant
filter, there is no way to control each grain's individual
resonance frequency.
It is - as said have a look at Ex. 1e from miSCellaneous lib which
is doing just that, per-grain filter effect -
Exactly, you divide the triggers and mix. So you have to be very good
guessing the number of voices you need, and CPU always runs all voices
no matter if you're using them or not. (trigRate varies in my case).
As usual with SynthDefs the maximum channel number is fixed
and you can use less by zeropadding.
'Voices' in this example means the maximum number of overlapping
grains, the 'overlap' param. Haven't tested with TGrains,
but with GrainBuf it's limited to 512 - which should be sufficient
for most use cases.
The mapping to output channels on the other hand
might still be handled in a flexible way, just like triggering
filter frequencies per grain, grouping and routing grain chunks to different
outputs can be triggered dynamically.
I suppose this to become a quite unpleasant index fiddling,
but it might pay (compared to Pbind granulation) if you do CPU-heavy granulations
and could be an interesting possibility for spatialization effects.
Greetings
Daniel
-----------------------------
www.daniel-mayer.at
-----------------------------
_______________________________________________
sc-users mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
James Harkins
2014-10-08 23:24:29 UTC
Permalink
Post by Hanns Holger Rutz
The only solution for that (apart from all-client side which is not
feasible in my case) would be to build polyphony from scratch on the
server side. The problem is that scsynth doesn't have a mechanism that
would keep unused voices idle (if I'm not mistaken), so with `Select`
and co you will end up wasting a lot of CPU resources.
The mechanism in scsynth for dynamically allocating synthesis units is
/s_new. If the triggering rate is below, oh, 40-50 grains/sec, defining a
SynthDef for one and only one grain and controlling it by a pattern should
work. Otherwise, you could take a hybrid approach: one SynthDef handles,
say, 3 or 4 grains. Triggers would come from a "master control" synth and
go onto control buses. The control synth could also pause and unpause the
child nodes as needed [1]. This wouldn't be easy but... perhaps feasible?

(I'm going into three consecutive very busy days, so I won't have time to
write a prototype for this approach.)

hjh

[1] http://doc.sccode.org/Classes/Pause.html

Sent with AquaMail for Android
http://www.aqua-mail.com



_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Daniel Mayer
2014-10-09 01:01:51 UTC
Permalink
Post by Hanns Holger Rutz
The only solution for that (apart from all-client side which is not
feasible in my case) would be to build polyphony from scratch on the
server side. The problem is that scsynth doesn't have a mechanism that
would keep unused voices idle (if I'm not mistaken), so with `Select`
and co you will end up wasting a lot of CPU resources.
The mechanism in scsynth for dynamically allocating synthesis units is /s_new. If the triggering rate is below, oh, 40-50 grains/sec, defining a SynthDef for one and only one grain and controlling it by a pattern should work. Otherwise, you could take a hybrid approach: one SynthDef handles, say, 3 or 4 grains. Triggers would come from a "master control" synth and go onto control buses. The control synth could also pause and unpause the child nodes as needed [1]. This wouldn't be easy but... perhaps feasible?
Yes, hybrid approaches are very interesting in this regard.
I haven't tried the specific one you're describing here, James, but others (Examples 3x in my tutorial).
To keep the overlap size variable without wasting CPU - though it might well be that
this is not a real restriction, rather disturbing by being 'ugly' -
I could also think of driving 'granular clouds' - as already named here on the list -
synths with Demand rate ugens, triggered by a Pattern/Player.
This would be a variant of Ex. 3d.
To adapt it for variable overlap sizes you could generate
a number of SynthDefs with overlap sizes up to the max you need ('SynthDef factory').
The Pattern (or other client-side control) would then be defined to select the
synthdefs with sizes needed for granular clouds.
This way Event durations would define the times between
changes of the overlap param - resp. the beginnings of changes as they
would depend on trigRates and overlappings of granular clouds also.
So a bit of blurring, but the client-side control wouldn't be complicated.

Regards

Daniel

-----------------------------
www.daniel-mayer.at
-----------------------------




_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Hanns Holger Rutz
2014-10-09 08:20:24 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks James,

if I come up with a general implementation in my system, I'll
definitely go the Pause route I think. But it means a lot of
scaffolding in my client (establish buses and cross-synth linking
mainly), so postponed to indefinite future :)

best, .h.h.
Post by James Harkins
Post by Hanns Holger Rutz
The only solution for that (apart from all-client side which is
not feasible in my case) would be to build polyphony from scratch
on the server side. The problem is that scsynth doesn't have a
mechanism that would keep unused voices idle (if I'm not
mistaken), so with `Select` and co you will end up wasting a lot
of CPU resources.
The mechanism in scsynth for dynamically allocating synthesis units
is /s_new. If the triggering rate is below, oh, 40-50 grains/sec,
defining a SynthDef for one and only one grain and controlling it
by a pattern should work. Otherwise, you could take a hybrid
approach: one SynthDef handles, say, 3 or 4 grains. Triggers would
come from a "master control" synth and go onto control buses. The
control synth could also pause and unpause the child nodes as
needed [1]. This wouldn't be easy but... perhaps feasible?
(I'm going into three consecutive very busy days, so I won't have
time to write a prototype for this approach.)
hjh
[1] http://doc.sccode.org/Classes/Pause.html
Sent with AquaMail for Android http://www.aqua-mail.com
_______________________________________________ sc-users mailing
list
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
http://www.listarc.bham.ac.uk/lists/sc-users/search/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUNkVEAAoJEKZFmaPaYk6QljIP/AyyGTeUHEWDDUJ0l4/oX9om
ywzKhQsiObMOzvinvAApORKqdce8IjxzYlyuzTVsdnwBXVO/bnUhkxMD0K3y0wi8
UT8vjnexEvTgMs/GQQIBevlwPBzlDgUa8MuEp2evyhlW5uZZuMu+3h09fv7IQzTG
VPT8DaqHL9xwuXxl04et/E9rFwBLfdeH11Fylo1fAPszBByXxJaBsCeWC7rMcFfV
loM2yR3ECSoq7hdNlCxRyGTBxU6J6UxXR1Ym2ry6qiFzTDLH8HIsIGNBkCcbCP3Z
SfpDMO/yRpGQLyFrzv/EWxC6Xl8kZW5SknWb/t/zjFocjBbajB5BEIx0BB8ww7RM
iA4HyYleg6Ar/dIDm+AdwACSDGAdzJEbD07330a29VVEmFpFBvB28NUEM8BcCpNU
Lkj/pokrEy7T9QHGkhBuCmiPuObQEd8QdzWBRKvJKiOWArP91znBqJfdsn4/26DN
bUTgL1lGNS24VUFCSF7jzoMcyL/AXmXHjxjI81D9pwlKtXHcX6qqSL8Vz5mL97OQ
xydiolj9hW1h2GQsP/7cihqb7oEbeWoU6pQVPJAjI7NYegOYscZi3579xcq3Tj2J
MZTCjg06cdVxk/swMTJWjVrJxnP9/uNL4K1OU/FEb0gmvqWuUZv6P71wxgia8i8S
ytr52LgA7VWhn8tbFhUX
=ylxp
-----END PGP SIGNATURE-----

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

Daniel Mayer
2014-10-08 15:26:38 UTC
Permalink
Post by Daniel Mayer
Post by Hanns Holger Rutz
Does anyone know how TGrains and TGrains2 handle polyphony - is that
dynamically allocated and unlimited, or is there an internal max
number of voices?
Hi Hanns Holger,
in the sense of per-grain parameter control and fx handling
polyphony can be done with TGrains and a multichannel trigger,
but it's rather tricky, Julian suggested this way
(the PulseDivider discussion we had then, also started here)
http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/per-grain-control-of-amplitude-in-GrainFM-td7598072.html
As this cascading issue costed me some hours of
walking through false thought loops and PulseDivider is used
in the example 1e it might be of interest for others too:

http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/PulseDivider-start-arg-td7598216.html

Regards

Daniel

-----------------------------
www.daniel-mayer.at
-----------------------------


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Loading...