> On Jul 5, 2020, at 12:00 PM, pd-list-request(a)lists.iem.at wrote:
>
> Date: Sat, 4 Jul 2020 22:25:55 +0200
> From: Antoine Villeret <antoine.villeret(a)gmail.com <mailto:antoine.villeret@gmail.com>>
> To: Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] Pd 0.50-2 on macos 11.0 BigSur beta
> Message-ID:
> <CAGn5wNdPE4PqDCNiXEQLpP=NTPy33P+e0b=iXvSs8t=pYif6qg(a)mail.gmail.com <mailto:CAGn5wNdPE4PqDCNiXEQLpP=NTPy33P+e0b=iXvSs8t=pYif6qg@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Miller,
>
> 0.51-0 ? How could I have missed it ?
> but this is the same as with 0.50-2 : patcher window is not rendered but Pd
> Console does.
Try this build: Pd-0.50-0-saveas-fix-tk867.zip <http://docs.danomatika.com/pdbuilds/0.51/Pd-0.50-0-saveas-fix-tk867.zip> It may have permissions issues, but you should be able to see if the canvas renders. It's a previous test build with the Tcl / Tk 8.6 frameworks included.
Putting aside the fact you are are asking for support for running Pd on the *first beta* of an un-released OS, the likely culprit is, as usual, Tk. The development of Tk on macOS is pretty slow and behind on support using the Cocoa frameworks. Basically, everything worked well with the previous Carbon frameworks, but we still have continuing problems with bugs related to the switch to Cocoa. This is not a "damn Apple changes everything all the time" issue but a "Apple warned us about the transition many years ahead, but everything worked and we didn't bother to deal with it until it was almost too late" issue. My impressions is that there is maybe only 1 or 2 Tk developers keeping things working on macOS.
Currently, we are distributing Pd for macOS with the Tcl / Tk 8.5 frameworks included which are built manually and applying a couple of custom patches. This works for now, but is not sustainable as newer systems can longer build Tk 8.5 (mine included) *and* we have perhaps now hit the point to where newer systems will also need a newer version of Tk to run Pd at all.
The best solution would be to provide a native Cocoa build with Tk as Cocoa itself is *very* stable in my experience, but that is for another discussion.
> I also tried to install XQuartz and run Pd from its terminal.
> No more success unfortunately.
That will not help as XQuartz has not been needed by newer Pd versions on macOS for many years now.
> Don't hesitate to ask me if I can help doing more tests.
> And please, avoid buying a Mac...
I have intimated this before, but perhaps I should now just say it:
Can some institution which relies on using Pd with macOS simply buy Miller and/or the Pd community a new Mac mini to support development efforts on the platform for the next 10 years? This is not too much to ask, especially if you lump it into the "year end" budget category.
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
Hello hello,
I want to share with you One Sample OSC 1 & 2.
These are two Pd vanilla abstractions for unconventional sample accurate audio processing.
Thanks to Camomile, they are also available as VST plugins.
The project is part of my research on and PhD thesis about sampling. I am about to finish the thesis this summer and so hopefully be able to share a bit later... ;)
Happy to hear back from you, if you feel like commenting on my approach. ;)
Best, Tobias
Have a look/listen here:
https://hartmanntobias.com/sampling/
Download here:
https://github.com/tob-har/one_sample_osc/releases
About the project:
https://github.com/tob-har/one_sample_osc
Tobias Hartmann
Künstlerisch-wissenschaftlicher Mitarbeiter exMedia - Sound
t.hartmann(a)khm.de (mailto:t.hartmann@khm.de)
+49 221 20 189 228 (tel:+49%20221%2020%20189%20228)
Peter-Welter-Platz 2 (https://maps.google.com/?q=Peter-Welter-Platz%202)
http://www.hartmanntobias.com
Dear list,
here's a new pre-release for the AoO multichannel audio streaming
library. In the last two months, the library has been seen many
improvements and has been used successfully in our Virtual Rehearsal
Room project (see vrr.iem.at <https://vrr.iem.at/>).
Binaries for all common platforms (Windows, macOS, Linux, ARM boards)
are available on Deken (search for "aoo"). The source code can be found
here: https://git.iem.at/cm/aoo
See the help patches (aoo_send~-help.pd, aoo_receive~-help.pd,
aoo_server.pd) for usage instructions.
If you want to stream between different home networks (without port
forwarding), you can use [aoo_client] and connect to our public AoO
server at the IEM (hostname: vrr.iem.at, port: 7077). You can easily set
up your own AoO server by running a Pd patch containing [aoo_server
<port>] on your web server.
---
Selected features:
# create audio networks of any topology with arbitrary ad-hoc connections
# [aoo_send~] / [aoo_receive~] take a port number and ID, so multiple
objects (within a single Pd instance) can operate on the same port.
Additionally, you can have multiple objects across different Pd
instances (using different port numbers).
# [aoo_send~] can stream to several destinations simultaneously;
# [aoo_receive~] can receive several AoO streams simultaneously, summing
the signals
# AoO is connectionless: streams can start/stop at any time, enabling a
"message-based audio" approach.
# AoO sinks can "invite" sources, i.e. ask them to send audio. The source
may follow the invitation or decline it.
# AoO sinks and sources can operate at different blocksizes and samplerates
# the streaming format can be set independently for each source; currently
only PCM (uncompressed) and Opus (compressed) are implemented, but this
can be easily extended with the AoO codec plugin API.
# audio encoding/decoding is multithreaded
# adjustable resending mechanism for dropped packets
# adjustable jitter buffer size.
# [aoo_server] / [aoo_client] implement the UDP hole punching technique to
establish peer2peer connections between different home networks.
# AoO is actually a C++ library with a C interface, so it can be used in
apps or embedded devices (like the ESP32). An implementation for
Supercollider is already planned.
---
For questions, bug reports or feature requests, please open an issue at
https://git.iem.at/cm/aoo/-/issues. We're very happy about any kind of
feedback!
Christof
_______________________________________________
Pd-announce mailing list
Pd-announce(a)lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
Hi,
> and tried to install aoo via deken, but it does not show up
that's weird. You should get
aoo[v2.0-pre2](Darwin-amd64-32)(Linux-amd64-32)(Linux-arm64-32)(Linux-armv7-32)(Linux-i386-32)(Windows-amd64-32)(Windows-i386-32).dek
"Linux-armv7-32" should run on the Raspberry Pi.
Can you try searching for libraries like "else" or "cyclone" which have
dedicated Armv7 versions and see if they show up?
Christof
PS: In the Deken settings you can disable "hide incompatible externals",
so the result should definitely show up in the next search.
On 29.06.2020 10:10, Frederic Robinson wrote:
> Hi,
>
>> The vision of AoO is that a network of computers becomes a modular system
>>
> i love that vision!
>
>> an ensemble of cheap wireless I/O devices
>>
> I have a mobile modular system of Raspberry Pis running PD with local
> speakers and sensors , and tried to install aoo via deken, but it does
> not show up. I suppose aoo currently does not run on that
> architecture? (sorry, my technical knowledge is limited..)
>
> best
> f
>
> --
> Frederic Robinson
> Scientia PhD Candidate || Spatial Sonic Interaction Design
> @ UNSW Creative Robotics Lab & Interactive Media Lab
> https://robinson.audio | +61 478 429 800‬
> On 24 Jun 2020, 19:49 +1000, Christof Ressi <info(a)christofressi.com>,
> wrote:
>>
>> Hi,
>>
>> the first use case was an audio installation by Bill Fontana in Graz
>> (March - June) where we placed environmental streaming devices at 8
>> different places in the city and streamed the sounds to other places.
>>
>> Then we used in April-June for the VRR project (https://vrr.iem.at/)
>> where students of contemporary classical music, who couldn't leave
>> their cities/countries because of the Covid restrictions, could
>> rehearse in a virtual rehearsal room which we've implemented in Pd.
>> Currently it's being used in computer music seminars where students
>> play as an ensemble of interconnected instruments.
>>
>> The vision of AoO is that a network of computers becomes a modular
>> system: every device can be connected to any other device on the fly.
>> For example, I might want to send 5 seconds of sound to player A,
>> then receive 4 seconds from player B, do something with and send the
>> result to some (wireless) speakers, etc.
>>
>> Another idea is to have an ensemble of cheap wireless I/O devices
>> (microphone + amplifier) running the AoO library (C++) as a portable
>> multichannel system.
>>
>> Christof
>>
>> On 24.06.2020 09:04, Frederic Robinson wrote:
>>> Hi Christof,
>>>
>>> That sounds very exciting! I’ll try this out as soon as I can.
>>>
>>>> In fact, that is one of the main use cases for this library ;-)
>>> I’m curious, what kind of projects did you use this in?
>>>
>>> Best regards,
>>> Frederic
>>>
>>>
>>> --
>>> Frederic Robinson
>>> Scientia PhD Candidate || Spatial Sonic Interaction Design
>>> @ UNSW Creative Robotics Lab & Interactive Media Lab
>>> https://robinson.audio | +61 478 429 800‬
>>> On 23 Jun 2020, 10:05 +1000, Christof Ressi
>>> <info(a)christofressi.com>, wrote:
>>>>
>>>> Hi,
>>>>
>>>>> Do you have experience with sending from one source to multiple
>>>>> devices via Wifi?
>>>> Sure, we did this all the time. In fact, that is one of the main
>>>> use cases for this library ;-)
>>>>
>>>> If you send within a private network, you can use the "pcm" format
>>>> for uncompressed audio, but for the public internet you might
>>>> consider using the "opus" format for substantially lower bandwidth,
>>>> especially when you're sending to many endpoints. A stereo 16-bit
>>>> PCM stream @ 44.1 kHz takes about 1.4 Mbit/s. With Opus you can set
>>>> the bandwidth to 120000 (= 128 kBit/s) and still get decent
>>>> quality. This means you can send 11 opus stream for a single PCM
>>>> stream :-)
>>>>
>>>> Christof
>>>>
>>>> On 23.06.2020 01:28, Frederic Robinson wrote:
>>>>> Dear Christof,
>>>>>
>>>>> I just learned about this library. Looks amazing, great work!
>>>>>
>>>>> Do you have experience with sending from one source to multiple
>>>>> devices via Wifi?
>>>>>
>>>>> Best regards,
>>>>> Frederic
>>>>>
>>>>>
>>>>> --
>>>>> Frederic Robinson
>>>>> Scientia PhD Candidate || Spatial Sonic Interaction Design
>>>>> @ UNSW Creative Robotics Lab & Interactive Media Lab
>>>>> https://robinson.audio | +61 478 429 800‬
>>>>> On 22 Jun 2020, 23:22 +1000, Christof Ressi
>>>>> <info(a)christofressi.com>, wrote:
>>>>>>
>>>>>> Dear list,
>>>>>>
>>>>>> here's a new pre-release for the AoO multichannel audio streaming
>>>>>> library. In the last two months, the library has been seen many
>>>>>> improvements and has been used successfully in our Virtual
>>>>>> Rehearsal Room project (see vrr.iem.at <https://vrr.iem.at/>).
>>>>>>
>>>>>> Binaries for all common platforms (Windows, macOS, Linux, ARM
>>>>>> boards) are available on Deken (search for "aoo"). The source
>>>>>> code can be found here: https://git.iem.at/cm/aoo
>>>>>>
>>>>>> See the help patches (aoo_send~-help.pd, aoo_receive~-help.pd,
>>>>>> aoo_server.pd) for usage instructions.
>>>>>>
>>>>>> If you want to stream between different home networks (without
>>>>>> port forwarding), you can use [aoo_client] and connect to our
>>>>>> public AoO server at the IEM (hostname: vrr.iem.at, port: 7077).
>>>>>> You can easily set up your own AoO server by running a Pd patch
>>>>>> containing [aoo_server <port>] on your web server.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Selected features:
>>>>>>
>>>>>> * create audio networks of any topology with arbitrary ad-hoc
>>>>>> connections
>>>>>> * [aoo_send~] / [aoo_receive~] take a port number and ID, so
>>>>>> multiple objects (within a single Pd instance) can operate on
>>>>>> the same port. Additionally, you can have multiple objects
>>>>>> across different Pd instances (using different port numbers).
>>>>>> * [aoo_send~] can stream to several destinations simultaneously;
>>>>>> * [aoo_receive~] can receive several AoO streams
>>>>>> simultaneously, summing the signals
>>>>>> * AoO is connectionless: streams can start/stop at any time,
>>>>>> enabling a "message-based audio" approach.
>>>>>> * AoO sinks can "invite" sources, i.e. ask them to send audio.
>>>>>> The source may follow the invitation or decline it.
>>>>>> * AoO sinks and sources can operate at different blocksizes and
>>>>>> samplerates
>>>>>> * the streaming format can be set independently for each
>>>>>> source; currently only PCM (uncompressed) and Opus
>>>>>> (compressed) are implemented, but this can be easily extended
>>>>>> with the AoO codec plugin API.
>>>>>> * audio encoding/decoding is multithreaded
>>>>>> * adjustable resending mechanism for dropped packets
>>>>>> * adjustable jitter buffer size.
>>>>>> * [aoo_server] / [aoo_client] implement the UDP hole punching
>>>>>> technique to establish peer2peer connections between
>>>>>> different home networks.
>>>>>> * AoO is actually a C++ library with a C interface, so it can
>>>>>> be used in apps or embedded devices (like the ESP32). An
>>>>>> implementation for Supercollider is already planned.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> For questions, bug reports or feature requests, please open
>>>>>> an issue at https://git.iem.at/cm/aoo/-/issues. We're very
>>>>>> happy about any kind of feedback!
>>>>>>
>>>>>> Christof
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pd-announce mailing list
>>>>>> Pd-announce(a)lists.iem.at
>>>>>> https://lists.puredata.info/listinfo/pd-announce
>>>>>>