Re: [PD] [PD-announce] VRR - Streaming Concert - 2020, June 5 & 6 - IEM Graz

[Christof Ressi]

Thanks a lot, Miller! Hearing this from you means a lot to us!

By the way, we will publish the concert material and some more 
documentation on our website in the next few days.


Christof

On 06.06.2020 19:26, Miller Puckette via Pd-list wrote:

Yes, bravo!

It's quite something to be able to see clearly how musical gestures
work out differently over networks than they do live in a room.  Every
composition student should watch this.

Aso I have no idea how you all managed to make this work :)

M

On Sat, Jun 06, 2020 at 06:22:04PM +0100, Julian Brooks wrote:

This is dope...

On Fri, 5 Jun 2020 at 07:30, Julian Brooks  wrote:


This looks great, some very fine pieces there - will be tuning in.
Nicely documented webpage too, am certainly curious re tech-setup.
Much props all round,

J

On Thu, 4 Jun 2020 at 03:26, Christof Ressi 
wrote:


Dear list,

I would like to announce our VRR streaming concerts, a cooperation
between the IEM Graz and the PPCM (performance practice of contemporary
music) studies at the University of Arts Graz, led by members of the
Klangforum Wien.

During the last 6 weeks we have been rehearsing in our Virtual Rehearsal
Room (VRR), which has been built entirely in Pd, using the AoO (audio
over OSC) external for high quality and low latency audio streaming. The
students are playing in their living rooms in different cities across 4
countries (Austria, Slovenia, Serbia and Norway). We will now present
the final results in two live concerts, featuring 8 pieces for 3???7
players by John Cage, Anestis Logothetis, Roman Haubenstock-Ramati,
Winfried Ritsch and Peter Ablinger.

Concert I: Friday, June 5, 2020, 18:00 CEST (16:00 UTC)

Concert II: Saturday, June 6, 2020, 18:00 CEST (16:00 UTC)

Location and info: 
https://urldefense.com/v3/__https://vrr.iem.at/concerts/__;!!Mih3wA!WHlphPXMx4jTXoeCpqYQhqAynq0Ex_1XLi3625oVjulQVS4e5b7q87gBW7oG$

Best,

Christof




___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-announce__;!!Mih3wA!WHlphPXMx4jTXoeCpqYQhqAynq0Ex_1XLi3625oVjulQVS4e5b7q8_kvJVI9$


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!WHlphPXMx4jTXoeCpqYQhqAynq0Ex_1XLi3625oVjulQVS4e5b7q89Dp5dgo$




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] VRR - Streaming Concert - 2020, June 5 & 6 - IEM Graz

[Miller Puckette via Pd-list]

Yes, bravo!

It's quite something to be able to see clearly how musical gestures
work out differently over networks than they do live in a room.  Every
composition student should watch this.

Aso I have no idea how you all managed to make this work :)

M

On Sat, Jun 06, 2020 at 06:22:04PM +0100, Julian Brooks wrote:
> This is dope...
> 
> On Fri, 5 Jun 2020 at 07:30, Julian Brooks  wrote:
> 
> > This looks great, some very fine pieces there - will be tuning in.
> > Nicely documented webpage too, am certainly curious re tech-setup.
> > Much props all round,
> >
> > J
> >
> > On Thu, 4 Jun 2020 at 03:26, Christof Ressi 
> > wrote:
> >
> >> Dear list,
> >>
> >> I would like to announce our VRR streaming concerts, a cooperation
> >> between the IEM Graz and the PPCM (performance practice of contemporary
> >> music) studies at the University of Arts Graz, led by members of the
> >> Klangforum Wien.
> >>
> >> During the last 6 weeks we have been rehearsing in our Virtual Rehearsal
> >> Room (VRR), which has been built entirely in Pd, using the AoO (audio
> >> over OSC) external for high quality and low latency audio streaming. The
> >> students are playing in their living rooms in different cities across 4
> >> countries (Austria, Slovenia, Serbia and Norway). We will now present
> >> the final results in two live concerts, featuring 8 pieces for 3???7
> >> players by John Cage, Anestis Logothetis, Roman Haubenstock-Ramati,
> >> Winfried Ritsch and Peter Ablinger.
> >>
> >> Concert I: Friday, June 5, 2020, 18:00 CEST (16:00 UTC)
> >>
> >> Concert II: Saturday, June 6, 2020, 18:00 CEST (16:00 UTC)
> >>
> >> Location and info: 
> >> https://urldefense.com/v3/__https://vrr.iem.at/concerts/__;!!Mih3wA!WHlphPXMx4jTXoeCpqYQhqAynq0Ex_1XLi3625oVjulQVS4e5b7q87gBW7oG$
> >>  
> >>
> >> Best,
> >>
> >> Christof
> >>
> >>
> >>
> >>
> >> ___
> >> Pd-announce mailing list
> >> pd-annou...@lists.iem.at
> >> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-announce__;!!Mih3wA!WHlphPXMx4jTXoeCpqYQhqAynq0Ex_1XLi3625oVjulQVS4e5b7q8_kvJVI9$
> >>  
> >>
> >

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!WHlphPXMx4jTXoeCpqYQhqAynq0Ex_1XLi3625oVjulQVS4e5b7q89Dp5dgo$
>  




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] VRR - Streaming Concert - 2020, June 5 & 6 - IEM Graz

[Julian Brooks]

This is dope...

On Fri, 5 Jun 2020 at 07:30, Julian Brooks  wrote:

> This looks great, some very fine pieces there - will be tuning in.
> Nicely documented webpage too, am certainly curious re tech-setup.
> Much props all round,
>
> J
>
> On Thu, 4 Jun 2020 at 03:26, Christof Ressi 
> wrote:
>
>> Dear list,
>>
>> I would like to announce our VRR streaming concerts, a cooperation
>> between the IEM Graz and the PPCM (performance practice of contemporary
>> music) studies at the University of Arts Graz, led by members of the
>> Klangforum Wien.
>>
>> During the last 6 weeks we have been rehearsing in our Virtual Rehearsal
>> Room (VRR), which has been built entirely in Pd, using the AoO (audio
>> over OSC) external for high quality and low latency audio streaming. The
>> students are playing in their living rooms in different cities across 4
>> countries (Austria, Slovenia, Serbia and Norway). We will now present
>> the final results in two live concerts, featuring 8 pieces for 3—7
>> players by John Cage, Anestis Logothetis, Roman Haubenstock-Ramati,
>> Winfried Ritsch and Peter Ablinger.
>>
>> Concert I: Friday, June 5, 2020, 18:00 CEST (16:00 UTC)
>>
>> Concert II: Saturday, June 6, 2020, 18:00 CEST (16:00 UTC)
>>
>> Location and info: https://vrr.iem.at/concerts/
>>
>> Best,
>>
>> Christof
>>
>>
>>
>>
>> ___
>> Pd-announce mailing list
>> pd-annou...@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-announce
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] pd 0.51-0 released

[Claude Heiland-Allen]

Hi all,

On 06/06/2020 03:50, Miller Puckette via Pd-announce wrote:

Pd version 0.51-0 is available on http://msp.ucsd.edu/software.htm
or (source only) via github: https://github.com/pure-data/pure-data .

Great!

I updated my forks for compiling libpd with emscripten to run in web 
browsers, instructions and build scripts at:

https://mathr.co.uk/empd/

Note that the updated network stuff is not supported by emscripten 
afaict (or maybe it's just a missing link library flag?), I don't know 
if there is a better workaround than ignoring missing symbols at link 
time and just not using the networking objects:

https://github.com/claudeha/pure-data/issues/5
Or maybe using the WinXP fallback code (minus IPv6) might work?  To be 
investigated...


I haven't yet retouched the experimental Gem stuff, probably it 
works/fails better/worse than a year ago.



Claude
--
https://mathr.co.uk




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [clone] with individual signal inlets/outlets exposed ?

[Alexandre Torres Porres]

Em sáb., 6 de jun. de 2020 às 07:42, hans w. koch 
escreveu:

> +1 for dynamic change in instance numbers
>
> has come up here before…


I'm surprised it hasn't been listed on github's issues, until now
https://github.com/pure-data/pure-data/issues/1055
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [clone] with individual signal inlets/outlets exposed ?

[Alexandre Torres Porres]

Em sáb., 6 de jun. de 2020 às 05:32, baptiste chatel <
baptiste.cha...@gmail.com> escreveu:

> I wish i was as skilled as you think i am !
> I'm the one impressed by your work with Cyclone and Else while describing
> yourself as not so skilled in the externals programming domain :)
>

As a musician, what you have to do is programm by ear :) - now, don't be
too impressed with my work on cyclone, the most impressive work needs to be
credited to Derek Kwan and Matt Barber, I literally knew nothing when we
started ;)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] pd 0.51-0 released

[hans w. koch]

usually the changes are documented here:
http://msp.ucsd.edu/Pd_documentation/x5.htm

best
hans

> Am 06.06.2020 um 12:56 schrieb Peter P. :
> 
> Thank you so much Miller!
> 
> I can't seem to find some changelog or info for users what has changed.
> Where would I best look? src/CHANGELOG seems to be rather old.
> 
> best, P
> 
> * Miller Puckette via Pd-announce  [2020-06-06 
> 04:51]:
>> To Pd-announce:
>> 
>> Pd version 0.51-0 is available on http://msp.ucsd.edu/software.htm
>> or (source only) via github: https://github.com/pure-data/pure-data .
>> 
>> cheers
>> Miller
>> 
>> 
>> 
>> ___
>> Pd-announce mailing list
>> pd-annou...@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-announce
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] pd 0.51-0 released

[Peter P.]

Oh thanks Hans, I always forget!

cheers, P

* hans w. koch  [2020-06-06 13:44]:
> usually the changes are documented here:
> http://msp.ucsd.edu/Pd_documentation/x5.htm
> 
> best
> hans
> 
> > Am 06.06.2020 um 12:56 schrieb Peter P. :
> > 
> > Thank you so much Miller!
> > 
> > I can't seem to find some changelog or info for users what has changed.
> > Where would I best look? src/CHANGELOG seems to be rather old.
> > 
> > best, P
> > 
> > * Miller Puckette via Pd-announce  [2020-06-06 
> > 04:51]:
> >> To Pd-announce:
> >> 
> >> Pd version 0.51-0 is available on http://msp.ucsd.edu/software.htm
> >> or (source only) via github: https://github.com/pure-data/pure-data .
> >> 
> >> cheers
> >> Miller
> >> 
> >> 
> >> 
> >> ___
> >> Pd-announce mailing list
> >> pd-annou...@lists.iem.at
> >> https://lists.puredata.info/listinfo/pd-announce
> >> ___
> >> Pd-list@lists.iem.at mailing list
> >> UNSUBSCRIBE and account-management -> 
> >> https://lists.puredata.info/listinfo/pd-list
> > 
> > 
> > 
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://lists.puredata.info/listinfo/pd-list
> 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] grey checkbox in Deken: Tri-Option? More questions and mailinglist archive search

[IOhannes m zmölnig]

On 6/6/20 12:52 PM, Peter P. wrote:
> Hi,
> 
> just found out that the checkbox for the Deken preference "Should newly
> installed libraries be added to Pd's search path?" has three states, on,
> off, and a grey check ("perhaps"?). What is its meaning?

yes, it's "perhaps". as in: ask the user every time they install a new
library.
the recommended way is of course to *not add search paths" and use
[declare -path ] in your patches instead.

> 
> What is the meaning of the "Check" button in front of some of the
> directories in the same dialog by the way? 

it means "Perform a check whether this path is writable".
paths that are greyed either don't exist (then you get a [Create]
button), or they do exist but the user cannot write to them (then you
have a [Check] button).
the [Check] button is there to allow the user to make the path writeable
(outside of Pd), and then check the path again.

i couldn't come up with a better name that is short enough to not
destroy the alignment of the preferences menu.

> What is the meaning of the
> line separators between some of the directory entries? 

they are separating between
- the currently chosen path
- the default search paths (those that Pd will automatically search for)
- user defined paths (added via the settings)

> Why is the
> ~/.local/lib/pd/extra directory present two times in this dialog on my
> Pd Debian installation?
> 

the first line showing you the currently selected path (which could be
anything, but happens to be ~/.local/lib/pd/extra on your system).
the 2nd occurence is part of the list of default search paths.


hope that makes sense.


mgfardss
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] pd 0.51-0 released

[Peter P.]

Thank you so much Miller!

I can't seem to find some changelog or info for users what has changed.
Where would I best look? src/CHANGELOG seems to be rather old.

best, P

* Miller Puckette via Pd-announce  [2020-06-06 04:51]:
> To Pd-announce:
> 
> Pd version 0.51-0 is available on http://msp.ucsd.edu/software.htm
> or (source only) via github: https://github.com/pure-data/pure-data .
> 
> cheers
> Miller
> 
> 
> 
> ___
> Pd-announce mailing list
> pd-annou...@lists.iem.at
> https://lists.puredata.info/listinfo/pd-announce
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] grey checkbox in Deken: Tri-Option? More questions and mailinglist archive search

[Peter P.]

Hi,

just found out that the checkbox for the Deken preference "Should newly
installed libraries be added to Pd's search path?" has three states, on,
off, and a grey check ("perhaps"?). What is its meaning?

What is the meaning of the "Check" button in front of some of the
directories in the same dialog by the way? What is the meaning of the
line separators between some of the directory entries? Why is the
~/.local/lib/pd/extra directory present two times in this dialog on my
Pd Debian installation?

Thank you for all hints!
P

PS: It would be great if the Mailinglist archive search would return
results which always show the messages' subjects. I do get mostly lines
of
"/pipermail/pd-list/attachments/20160610/6ffecf40/attachment.html"
There might be a reason/problem to the archive search engine...



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [clone] with individual signal inlets/outlets exposed ?

[hans w. koch]

+1 for dynamic change in instance numbers

has come up here before…

best
hans

> Am 06.06.2020 um 11:31 schrieb Dan Wilcox :
> 
> You are missing clone individual instance outlets and I’m missing dynamic 
> clone instance numbers.
> 
> I’d like to be able send a message to clone to change the number of instances 
> so the server could save a bit more resources beyond using [switch~]. This is 
> important for performance scaling between working on a project on a Macbook 
> Air then performing with it live on a Mac Pro in the studio. More 
> importantly, we have older projects which use large multi-channel files, so 
> it would be nice to dynamically change the sound file outputs individually up 
> to 32 channels. My only thought for these is to have separate *light* and 
> *heavy* server patches which load different instances of the main 
> abstractions with more or less numbers. Eh, seems clunky too.
> 
> enohp ym morf tnes
> ---
> Dan Wilcox
> danomatika.com
> robotcowboy.com
> 
> 
> On Jun 6, 2020, at 10:47 AM, baptiste chatel  
> wrote:
> 
>> That looks like an impressive bit of work !
>> I did something along thoses lines a while ago, while at a smaller scale. In 
>> the end, i guess the "clunkiness" was too much for me to deal with.
>> But that was pre intelligent patching era ! That's why i can now think about 
>> simply connecting multi-i/os objects (IEM ambisonics plugins with 
>> [vstplugin~]) together in a blink, and scale the number of i/o as i need 
>> without resorting to workarounds, and more importantly without having to 
>> re-engineer what looks like a simple thing (in my head, that is). So now i 
>> feel that since we can connect a great number of cable easily, we should be 
>> able to multiply objects in the same way.
>> 
>> 
>> 
>> Le ven. 5 juin 2020 à 21:22, Dan Wilcox  a écrit :
>> I think you can also be clever about the mixing and the outputs...
>> 
>> In my case, I usually end up with an output abstraction to [dac~]:
>> 
>> [receive~ out$1]
>> |
>> [*~] <--- some gain control input
>> |
>> [dac~ $1]
>> 
>> A use case would be the zirk_id -> zirk_speaker -> zirk_output handling in 
>> the ZKM Zirkonium server patches:
>> 
>> https://github.com/ZKM-IMA/ZirkoniumSpatializationServer
>> 
>> (It's currently macOS-only as it includes custom binaries for the 
>> spatialization algorithms. I will probably fix this by fall.)
>> 
>> In this case, Zirkonium has the following layout:
>> 
>> 64 live input channels
>> 64 input sound files (with 8 channels)
>> 64 IDs aka objects mapping between input channels (live or sound file) and 
>> spatialization algorithms to virtual speakers
>> 64 virtual speakers wich are mapped to outputs
>> 64 output dac~ wrappers
>> 
>> The ID objects & spat algo wrappers use additional clones internally to map 
>> each channel to all of the virtual speakers. I imagine a setup like this 
>> could work for you. A [zirk_vbap] object, for example, has an internal clone 
>> with [zirk_dispatcher]s which handle the connections between the named 
>> sends~/receives~. It's a little clunky but it works.
>> 
>> I think a bunch of giant 64-channel output objects would also be clunky and 
>> also work, but in a different way. :)
>> 
>>> On Jun 5, 2020, at 8:43 PM, baptiste chatel  
>>> wrote:
>>> 
>>> Clever, but you have to do a repetitive error-prone lengthy clicky process 
>>> either on the send side or on the receive side.
>>> Since in my case i have four 16-tracks sends to a 64 by 16 matrix (3rd 
>>> order ambisonics monitoring), i mitigated the issue by making an 
>>> abstraction containing 16 settable sends, taking a float as an argument for 
>>> the first send number. On the other side, i still had to make 64 unique 
>>> receives...
>>> 
>>> Le ven. 5 juin 2020 à 20:23, Dan Wilcox  a écrit :
>>> Your abstraction can have a named [send~] which you can receive into your 
>>> matrix. Use the $1 id assigned by clone to differentiate the sends, ie.
>>> 
>>> In abstraction:
>>> 
>>> |
>>> [send~ out$1]
>>> 
>>> For matrix:
>>> 
>>> [receive~ out1]  [receive~ out2] [receive~ out3]
>>> ||   |
>>> [matrix  -   -  ...]
>>> 
>>> etc
>>> 
>>> In this way, the [clone] itself has no outputs, but you have all of the 
>>> outputs via [send~]. I use this approach very often.
>>> 
 On Jun 5, 2020, at 7:49 PM, pd-list-requ...@lists.iem.at wrote:
 
 Message: 5
 Date: Fri, 5 Jun 2020 19:20:36 +0200
 From: baptiste chatel 
 To: Pd-List 
 Subject: [PD] [clone] with individual signal inlets/outlets exposed ?
 Message-ID:

 Content-Type: text/plain; charset="utf-8"
 
 Would it be possible to have a [clone] option that allows clones individual
 signal inlets/outlets to be exposed ?
 
 An example : i need to make 64 of the following patch :
 [receive~ thing-$1]
 |
 [outlet~]
 that should go to a matrix, $1 in [1:64].
 
 [clone] is useless because

Re: [PD] [clone] with individual signal inlets/outlets exposed ?

[Dan Wilcox]

You are missing clone individual instance outlets and I’m missing dynamic clone 
instance numbers.

I’d like to be able send a message to clone to change the number of instances 
so the server could save a bit more resources beyond using [switch~]. This is 
important for performance scaling between working on a project on a Macbook Air 
then performing with it live on a Mac Pro in the studio. More importantly, we 
have older projects which use large multi-channel files, so it would be nice to 
dynamically change the sound file outputs individually up to 32 channels. My 
only thought for these is to have separate *light* and *heavy* server patches 
which load different instances of the main abstractions with more or less 
numbers. Eh, seems clunky too.

enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com


> On Jun 6, 2020, at 10:47 AM, baptiste chatel  
> wrote:
> 
> That looks like an impressive bit of work !
> I did something along thoses lines a while ago, while at a smaller scale. In 
> the end, i guess the "clunkiness" was too much for me to deal with.
> But that was pre intelligent patching era ! That's why i can now think about 
> simply connecting multi-i/os objects (IEM ambisonics plugins with 
> [vstplugin~]) together in a blink, and scale the number of i/o as i need 
> without resorting to workarounds, and more importantly without having to 
> re-engineer what looks like a simple thing (in my head, that is). So now i 
> feel that since we can connect a great number of cable easily, we should be 
> able to multiply objects in the same way.
> 
> 
> 
>> Le ven. 5 juin 2020 à 21:22, Dan Wilcox  a écrit :
>> I think you can also be clever about the mixing and the outputs...
>> 
>> In my case, I usually end up with an output abstraction to [dac~]:
>> 
>> [receive~ out$1]
>> |
>> [*~] <--- some gain control input
>> |
>> [dac~ $1]
>> 
>> A use case would be the zirk_id -> zirk_speaker -> zirk_output handling in 
>> the ZKM Zirkonium server patches:
>> 
>> https://github.com/ZKM-IMA/ZirkoniumSpatializationServer
>> 
>> (It's currently macOS-only as it includes custom binaries for the 
>> spatialization algorithms. I will probably fix this by fall.)
>> 
>> In this case, Zirkonium has the following layout:
>> 
>> 64 live input channels
>> 64 input sound files (with 8 channels)
>> 64 IDs aka objects mapping between input channels (live or sound file) and 
>> spatialization algorithms to virtual speakers
>> 64 virtual speakers wich are mapped to outputs
>> 64 output dac~ wrappers
>> 
>> The ID objects & spat algo wrappers use additional clones internally to map 
>> each channel to all of the virtual speakers. I imagine a setup like this 
>> could work for you. A [zirk_vbap] object, for example, has an internal clone 
>> with [zirk_dispatcher]s which handle the connections between the named 
>> sends~/receives~. It's a little clunky but it works.
>> 
>> I think a bunch of giant 64-channel output objects would also be clunky and 
>> also work, but in a different way. :)
>> 
>>> On Jun 5, 2020, at 8:43 PM, baptiste chatel  
>>> wrote:
>>> 
>>> Clever, but you have to do a repetitive error-prone lengthy clicky process 
>>> either on the send side or on the receive side.
>>> Since in my case i have four 16-tracks sends to a 64 by 16 matrix (3rd 
>>> order ambisonics monitoring), i mitigated the issue by making an 
>>> abstraction containing 16 settable sends, taking a float as an argument for 
>>> the first send number. On the other side, i still had to make 64 unique 
>>> receives...
>>> 
 Le ven. 5 juin 2020 à 20:23, Dan Wilcox  a écrit :
 Your abstraction can have a named [send~] which you can receive into your 
 matrix. Use the $1 id assigned by clone to differentiate the sends, ie.
 
 In abstraction:
 
 |
 [send~ out$1]
 
 For matrix:
 
 [receive~ out1]  [receive~ out2] [receive~ out3]
 ||   |
 [matrix  -   -  ...]
 
 etc
 
 In this way, the [clone] itself has no outputs, but you have all of the 
 outputs via [send~]. I use this approach very often.
 
> On Jun 5, 2020, at 7:49 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Message: 5
> Date: Fri, 5 Jun 2020 19:20:36 +0200
> From: baptiste chatel 
> To: Pd-List 
> Subject: [PD] [clone] with individual signal inlets/outlets exposed ?
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Would it be possible to have a [clone] option that allows clones 
> individual
> signal inlets/outlets to be exposed ?
> 
> An example : i need to make 64 of the following patch :
> [receive~ thing-$1]
> |
> [outlet~]
> that should go to a matrix, $1 in [1:64].
> 
> [clone] is useless because it will sum all outputs and expose only one,
> since the cloned patch has one output.
> 
> I could do it with dynamic patc

Re: [PD] [clone] with individual signal inlets/outlets exposed ?

[baptiste chatel]

Yes, i know about intelligent patching. I must admit that all the shortcuts
are not stored in muscle memory yet !
But that does not solve the issue of having to duplicate and change the
argument of a great number of objects.
As i said to Dan, intelligent patching is so great now that having this
-mcin -mcout option added to [clone] looks like intelligent patching and
[clone] were made for each other !

Le ven. 5 juin 2020 à 21:25, IOhannes m zmölnig  a écrit :

> On 6/5/20 8:43 PM, baptiste chatel wrote:
> > Clever, but you have to do a repetitive error-prone lengthy clicky
> process
> > either on the send side or on the receive side.
>
> how so?
>
> https://vimeo.com/273707442
> https://vimeo.com/279631360
> https://vimeo.com/340437816
>
>
> gfmr
> IOhannes
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [clone] with individual signal inlets/outlets exposed ?

[baptiste chatel]

That looks like an impressive bit of work !
I did something along thoses lines a while ago, while at a smaller scale.
In the end, i guess the "clunkiness" was too much for me to deal with.
But that was pre intelligent patching era ! That's why i can now think
about simply connecting multi-i/os objects (IEM ambisonics plugins with
[vstplugin~]) together in a blink, and scale the number of i/o as i need
without resorting to workarounds, and more importantly without having to
re-engineer what looks like a simple thing (in my head, that is). So now i
feel that since we can connect a great number of cable easily, we should be
able to multiply objects in the same way.



Le ven. 5 juin 2020 à 21:22, Dan Wilcox  a écrit :

> I think you can also be clever about the mixing and the outputs...
>
> In my case, I usually end up with an output abstraction to [dac~]:
>
> [receive~ out$1]
> |
> [*~] <--- some gain control input
> |
> [dac~ $1]
>
> A use case would be the zirk_id -> zirk_speaker -> zirk_output handling in
> the ZKM Zirkonium server patches:
>
> https://github.com/ZKM-IMA/ZirkoniumSpatializationServer
>
> (It's currently macOS-only as it includes custom binaries for the
> spatialization algorithms. I will probably fix this by fall.)
>
> In this case, Zirkonium has the following layout:
>
> 64 live input channels
> 64 input sound files (with 8 channels)
> 64 IDs aka objects mapping between input channels (live or sound file) and
> spatialization algorithms to virtual speakers
> 64 virtual speakers wich are mapped to outputs
> 64 output dac~ wrappers
>
> The ID objects & spat algo wrappers use additional clones internally to
> map each channel to all of the virtual speakers. I imagine a setup like
> this could work for you. A [zirk_vbap] object, for example, has an internal
> clone with [zirk_dispatcher]s which handle the connections between the
> named sends~/receives~. It's a little clunky but it works.
>
> I think a bunch of giant 64-channel output objects would also be clunky
> and also work, but in a different way. :)
>
> On Jun 5, 2020, at 8:43 PM, baptiste chatel 
> wrote:
>
> Clever, but you have to do a repetitive error-prone lengthy clicky process
> either on the send side or on the receive side.
> Since in my case i have four 16-tracks sends to a 64 by 16 matrix (3rd
> order ambisonics monitoring), i mitigated the issue by making an
> abstraction containing 16 settable sends, taking a float as an argument for
> the first send number. On the other side, i still had to make 64 unique
> receives...
>
> Le ven. 5 juin 2020 à 20:23, Dan Wilcox  a écrit :
>
>> Your abstraction can have a named [send~] which you can receive into your
>> matrix. Use the $1 id assigned by clone to differentiate the sends, ie.
>>
>> In abstraction:
>>
>> |
>> [send~ out$1]
>>
>> For matrix:
>>
>> [receive~ out1]  [receive~ out2] [receive~ out3]
>> ||   |
>> [matrix  -   -  ...]
>>
>> etc
>>
>> In this way, the [clone] itself has no outputs, but you have all of the
>> outputs via [send~]. I use this approach very often.
>>
>> On Jun 5, 2020, at 7:49 PM, pd-list-requ...@lists.iem.at wrote:
>>
>> Message: 5
>> Date: Fri, 5 Jun 2020 19:20:36 +0200
>> From: baptiste chatel 
>> To: Pd-List 
>> Subject: [PD] [clone] with individual signal inlets/outlets exposed ?
>> Message-ID:
>> 
>> Content-Type: text/plain; charset="utf-8"
>>
>> Would it be possible to have a [clone] option that allows clones
>> individual
>> signal inlets/outlets to be exposed ?
>>
>> An example : i need to make 64 of the following patch :
>> [receive~ thing-$1]
>> |
>> [outlet~]
>> that should go to a matrix, $1 in [1:64].
>>
>> [clone] is useless because it will sum all outputs and expose only one,
>> since the cloned patch has one output.
>>
>> I could do it with dynamic patching, but as practical as it could be, it
>> is
>> pretty convoluted to use for such a simple need.
>>
>>
>> Baptiste
>>
>>
>> 
>> Dan Wilcox
>> @danomatika 
>> danomatika.com
>> robotcowboy.com
>>
>>
>>
>>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [clone] with individual signal inlets/outlets exposed ?

[baptiste chatel]

I wish i was as skilled as you think i am !
I'm the one impressed by your work with Cyclone and Else while describing
yourself as not so skilled in the externals programming domain :)

To add to the noise : your -mcin -mcout option idea is great ! Sure, there
are many ways to do without this in my case, but the general idea is to
improve on [clone] to be able to do quickly and simply things instead of
engineering convoluted workarounds (not trying to say that the work
involved by such an upgrade to [clone] is easy).

Actually, i would be very satisfied by :
- this -mcin -mcout option added to [clone]
- a new "duplicate and increment an arg by 1" feature, so i don't feel sad
and lonely because i have to rename 64 [receive]s.

Le ven. 5 juin 2020 à 21:10, Alexandre Torres Porres  a
écrit :

> I guess making noise on the list helps :) it narrows down to someone also
> feel it's worth it and implement it, aren't you a skilled fellow anyway? I
> think this one is over my head... I'm still only able to managing lower
> hanging fruits :P
>
> Em sex., 5 de jun. de 2020 às 15:30, baptiste chatel <
> baptiste.cha...@gmail.com> escreveu:
>
>> Is there a way to nicely "upvote" this request other than commenting the
>> issue ?
>>
>> Le ven. 5 juin 2020 à 20:16, Alexandre Torres Porres 
>> a écrit :
>>
>>> I already made that request by the way
>>> https://github.com/pure-data/pure-data/issues/500
>>>
>>> Em sex., 5 de jun. de 2020 às 14:51, baptiste chatel <
>>> baptiste.cha...@gmail.com> escreveu:
>>>
 Would it be possible to have a [clone] option that allows clones
 individual signal inlets/outlets to be exposed ?

 An example : i need to make 64 of the following patch :
 [receive~ thing-$1]
 |
 [outlet~]
 that should go to a matrix, $1 in [1:64].

 [clone] is useless because it will sum all outputs and expose only one,
 since the cloned patch has one output.

 I could do it with dynamic patching, but as practical as it could be,
 it is pretty convoluted to use for such a simple need.


 Baptiste


 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management ->
 https://lists.puredata.info/listinfo/pd-list

>>>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] shameless livestream plug, was: external binary file extensions for 32 and 64bit under recent OS X

[Christof Ressi]

Nice! I'll tune in.

On 05.06.2020 21:33, Dan Wilcox wrote:
Thanks for the segue, Peter. I was thinking about spamming this list 
with a non-Pd invite but held back. Now I'll piggy-back on your 
mention. :)


Also tomorrow night, (hopefully) after the IEM show at 6pm a band I 
play guitar in will be live online:


Kosmøthyczka (fem/punk/nowave/accordion) on the P8 Karlsruhe 
livestream @ 8pm CEST (1pm US Eastern, 11am US Pacific)


https://www.youtube.com/watch?v=0Mp-YeOc-6E

(Even when everything is online, events always find a way to happen on 
the same night. Gig-hopping is now link-hopping, so at least that's 
easier and possible for parents in these crazy times.)


Christof: IU second Peter, good luck tomorrow.

On Jun 5, 2020, at 9:14 PM, pd-list-requ...@lists.iem.at 
 wrote:


Message: 2
Date: Fri, 5 Jun 2020 20:46:13 +0200
From: "Peter P." >

To:pd-list@lists.iem.at 
Subject: Re: [PD] external binary file extensions for 32 and 64bit
under recent OS X
Message-ID: <20200605184613.rd3jhytkgtwdn...@fastmail.com 
>

Content-Type: text/plain; charset=us-ascii

Thanks for posting this excellent information, and so shortly before
yourhttps://vrr.iem.at/concerts/event! This is excellent and should be
preserved somewhere online for reference I find!
cheers, P



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list