[PD] [PD-announce] IEM Music Residency Program 2019 - Call for Applications

[IOhannes m zmoelnig]

IEM Music Residency Program 2019 - Call for Applications
https://iem.at

(sorry for cross-posting; please distribute)

The IEM - Institute of Electronic Music and Acoustics - in Graz, Austria
is happy to announce its call for the 2019 Artist-in-Residence program.

The residency is aimed at individuals wishing to pursue projects in
performance, composition, installation, sound art, development of tools
for art production, and related areas. Individuals are asked to submit a
project proposal that is related to the fields of artistic research of
the IEM, as:
*   Algorithmic Composition
* Algorithmic Experimentation
*   Audio-Visuality
*   Dynamical Systems
*   Experimental Game Design
*   Live Coding
*   Sonic Interaction Design
*   Spatialization/higher-order Ambisonics
*   Standard and non-standard Sound Synthesis

Duration of residency: 5 months
Start date: June 1st 2019 (negotiable)
Monthly salary: approx. EUR 1100 (net)

APPLICATION DEADLINE: 1st of May 2018

The Institute:
The Institute of Electronic Music and Acoustics is a department of the
University of Music and Performing Arts Graz founded in 1965. It is a
leading institution in its field, with more than 35 staff members of
researchers and artists. IEM offers education to students in composition
and computer music, sound engineering, sound design, contemporary music
performance, and musicology. It is well connected to the University of
Technology, the University of Graz as well as to the University of
Applied Sciences Joanneum through three joint study programs.

The artwork produced at IEM is released through the Institute's own Open
CUBE and Signale concert series, as well as through various
collaborations with international artists and institutions.

What we expect from applicants:
- A project proposal that adds new perspectives to the Institute's
activities and resonates well with the interests of IEM.
- Willingness to work on-site in Graz for the most part of the Residency.
- Willingness to exchange and share ideas, knowledge and results with
IEM staff members and students, and engage in scholarly discussions.
- The ability to work independently within the Institute.
- A dissemination strategy as part of the project proposal that ensures
the publication of the work, or documentation thereof, in a suitable
format. This could be achieved for example through the release of media,
journal or conference publication, a project website, or other means
that help to preserve the knowledge gained through the Music Residency
and make it available to the public.
- A public presentation as e.g. a concert or installation, which
presents the results of the Artist Residency.

What we offer:
- 24/7 access to the facilities of the IEM.
- Exchange with competent and experienced staff members.
- A desk in a shared office space for the entire period and access to
studios including the CUBE [1], according to availability.
- Extensive access to the studios of the IEM during the period from July
1st until end of September.
- access to the IKOsahedron loudspeaker [2]
- access to the “Autoklavierspieler” [3]
- infrared motion tracking systems
- Regular possibilities for contact and exchange with peers from similar
or other disciplines.
- Concert and presentation facilities (CUBE 24 channel loudspeaker
concert space).
- A monthly salary of approx. EUR 1100 net per month in addition to
health and accident insurance.

What we cannot offer to the successful applicant:
- We cannot provide any housing.
- We also cannot provide continuous assistance and support, although the
staff is generally willing to help where possible.
- We cannot host artist duos or groups, because of spatial limitations.
- We cannot offer any additional financial support for travel or
material expenses.

An application form providing more information is available at
https://residency.iem.at/

Feel free to contact reside...@iem.at if you have any questions.

[1] The Cube has a 24-channel loudspeaker system
[2] http://iko.sonible.com/
[3] http://algo.mur.at/projects/autoklavierspieler



signature.asc
Description: OpenPGP digital signature
___
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 on Tiny Core Linux on Raspberry Pi

[Thomas Grill]

That's how i performed the compilation - the process, including the separation 
of the results into -bin, -dev and -doc packages should be made reproducible 
with some scripts. That is the wish of the picore repo keepers.
best, Thomas

> Am 07.03.2018 um 15:48 schrieb Dan Wilcox :
> 
> It should work with makefile.gnu in src. We still need to update the 
> autotools setup to support the "build in place" approach beyond the halfway 
> symlinking it does now, so I wouldn't use the configure script et al. in the 
> package for this yet.
> 
>> On Mar 7, 2018, at 12:34 PM, Thomas Grill > > wrote:
>> 
>> Ah, i forgot... it would be cool for the future to have a buildable package 
>> with source included and working build scripts.
>> Don't know when/whether i have the time for that, so if someone wants to 
>> stand in, please go for it.
>> best, Thomas
>> 
>>> Am 07.03.2018 um 09:35 schrieb Thomas Grill >> >:
>>> 
>>> Dear all,
>>> puredata-0.48-1 is now in the PiCore repository! That's a binary build for 
>>> tinycorelinux on Raspberry Pi.
>>> http://repo.tinycorelinux.net/9.x/armv6/tcz/ 
>>> 
>>> best, Thomas
>>> 
>>> --
>>> Thomas Grill
>>> http://g.org
>>> 
>>> 
>>> 
 Am 16.02.2018 um 23:58 schrieb Thomas Grill :
 
 Dear all,
 i have just submitted picore extension packages for pd-0.48-1 to the 
 respective repertory.
 I hope i have met all the requirements, so that the package can become 
 canonical very soon.
 
 If you want to install them in the meantime, please grab the files from 
 http://l.g.org/puredata_tcz
 The manual installation procedure is the following:
 
 ---
 
 Copy the package files from your local machine to the tinycore:
 scp $SOURCEDIR/puredata.tcz{,.dep,.md5.txt} 
 tc@$TINYCOREIP:/etc/sysconfig/tcedir/optional/
 
 then logon to the tinycore:
 ssh tc@$TINYCOREIP
 chown tc.staff /etc/sysconfig/tcedir/optional/puredata.tcz*
 chmod 664 /etc/sysconfig/tcedir/optional/puredata.tcz*
 echo puredata.tcz >> /etc/sysconfig/tcedir/onboot.lst
 
 and reboot the tinycore
 
 ---
 
 These are just the binary files needed to run pd.
 The doc/help files are in the puredata-doc.tcz package, the development 
 header m_pd.h is in puredata-dev.tcz .
 To install those permanently, follow the procedure from above with changed 
 package names.
 
 best, Thomas
 
 --
 Thomas Grill
 http://g.org
 
 
 
> Am 15.02.2018 um 04:22 schrieb Dan Wilcox :
> 
> Sweet, good to know. I think it would be good if the Pd distribution 
> tarball was built this way so you don't need autoconf/autogen installed 
> to build.
> 
>> On Feb 15, 2018, at 4:20 AM, Chris McCormick  wrote:
>> 
>> Hi Dan,
>> 
>> On 07/02/18 16:50, Dan Wilcox wrote:
>>> Looks like an issue with autoconf of your system. If we used a dist 
>>> tarball with pregenerated configure scripts, this probably wouldn't be 
>>> an issue since then autoconf and automaker are not needed, just gcc and 
>>> make.
>> I followed your instructions to build the dist tarball:
>> 
>>> ./autogen.sh
>>> ./configure
>>> make dist
>> 
>> Then copied the tarball pd-0.48.1.tgz to the Raspberry Pi running Tiny 
>> Core Linux and ran:
>> 
>> ./configure
>> make
>> 
>> The resulting binary successfully runs a test tone Pd patch and outputs 
>> a sine wave to the audio jack.
>> 
>> Hope this helps!
>> 
>> Cheers,
>> 
>> Chris.
>> 
>> --
>> http://mccormick.cx/
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
 
>>> 
>> 
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 
> 
> 



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

Re: [PD] adding outlets to [inlet~] (was How can a signal inlet of an object know if it's receiving a signal)

[Alexandre Torres Porres]

yeah, but it's a completely different picture.

we're talking here about an "invisible" inlet. Please note that [inlet~]
does not actually have any real inlet on its box.

I was also assuming and pretty sure it'd be easy to handle both signal and
control data for [inlet~], but adding an inlet to a canvas is a completely
different process than adding an inlet to an object, and it really has to
be either a control inlet or an audio inlet.

Have a look at the code, where I highlighted it, this is it:
canvas_addinlet(x->x_canvas,
>x_obj.ob_pd, _signal);

As you can see, you need to specify if it is a signal or not.

And if we're talking about external coding, it is also actually the same
deal if you are adding secondary inlets to an object. You cannot have a
secondary inlet taking both a signal and a symbol input for instance. I can
only assume it is because of the same limitation.

cheers


2018-03-08 4:33 GMT-03:00 oliver :

>
> Yeah, I've been still trying around and now I'm pretty sure this is
>> where you set the type, and I'm also now assuming there's no way to
>> carry both signals and control data in the same input as it is. This
>> seems to require changes to the core of Pd elsewhere, right?
>>
>
> ???
>
> i don't think so ...
>
> [writesf~], [tabwrite~], [snapshot~] etc.
>
> all of them vanilla objects, all take signal AND message inputs
>
>
> best
>
> oliver
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
> stinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] deken v0.3.0: new fileformat for library packages

[Antoine Rousseau]

Thank you so much for this invaluable (and substantial...) work, which
still promises a long life to Pd, allowing everyone to bring his own stone
to the building!

Antoine Rousseau
  http://www.metalu.net  __
http://www.metaluachahuter.com/



2018-03-08 17:09 GMT+01:00 IOhannes m zmoelnig :

> we are proud to announce a major overhaul of the deken fileformat.
>
> TL;DR to download new deken packages, you will need at least version
> v0.3.0 of the deken-plugin (Pd-0.48-1 includes deken-v0.2.4).
> When searching externals with an old (incompatible) version of the
> plugin, you will always find a suggestion to install the new plugin with
> something like:
>
> > deken-plugin/0.3.0
> >  (Deken externals downloader - REQUIRED FOR NEW PACKAGES)
>
> once you have installed the new version (and/or Pd includes a compatible
> version), the nagging will stop :-)
>
>
> # fileformat
>
> the new fileformat fixes a number of issues we had with the existing one.
> things that are better:
> - cool filename extension '.dek'
> - consistent archival options for all platforms (ZIP!)
> - proper detection of the version string for all libraries (even if the
> library has a weird name like "a-v12"
> - support for double-precision externals (once Pd supports that!)
> - extensible
>
>
> # Pd-integration
> the updated "deken-plugin" has a number of nifty features, you don't
> want to miss:
> - support for the new fileformat
> - support for the old (legacy) fileformat
> - (optionally) uninstall libraries before re-installing them
> - (optionally) show a README that is included in the package on
> successful installation
> - set installation path (suggesting Pd's default search paths, and
> offering to create those that are missing)
> - (optionally) hides the search-results for incompatible platforms
> - (optionally) overrides the "compatible" Pd-architecture
> - nice preferences
> - bugfixes
> - much more
>
>
> # Developer tools
> if you are a developer of libraries, we have also updated our 'deken'
> cmdline tool.
> things you always wanted to have and which are now free:
> - support for the new fileformat (default)
> - support for the old (legacy) fileformat
> - better detection of binary architectures
> - better detection of included sources
> - (experimental) support for double-precision externals
> - pre-compiled & self-contained Windows binaries
> - bugfixes
> - much more
>
>
> if you want to know more, see
> - http://puredata.info/downloads/deken/releases/0.3.0/
> - https://lists.puredata.info/pipermail/pd-dev/2018-02/021513.html
> - https://github.com/pure-data/deken/issues/161
>
>
> i have submitted also submitted a Pull-Request to include the new
> deken-plugin into Pd proper:
> - https://github.com/pure-data/pure-data/pull/320
>
> and another Pull-Request for Pd that is required to make the
> double-precision detection work:
> - https://github.com/pure-data/pure-data/pull/300
>
>
> happy patching.
> fgm,asdr
> IOhannes
>
>
> ___
> 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

Re: [PD] [PD-announce] deken v0.3.0: new fileformat for library packages

[IOhannes m zmoelnig]

On 2018-03-08 17:46, Alexandre Torres Porres wrote:
> awesome!
> 
> 2018-03-08 13:09 GMT-03:00 IOhannes m zmoelnig :
> 
>>
>> - (optionally) show a README that is included in the package on
>> successful installation
>>
> 
> Can this be any file format, like a PDF? Or does it have to be .txt or
> something?

it has to be either a .pd, .html or .txt file, must be named:
 README.deken.pd (or similar) and must live inside the /
folder.
so if your package is "cyclone[v0.0](SystemV-pdp11-8).dek" this would be
"cyclone/README.deken.txt"

fgasdrm
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] deken v0.3.0: new fileformat for library packages

[JP Cimalando via Pd-list]

On Thu, 8 Mar 2018 17:09:02 +0100
IOhannes m zmoelnig  wrote:

> we are proud to announce a major overhaul of the deken fileformat.
> 
This is nice.

I have uploaded a few deks now. How do I make them show up in Pd?

I try to send objects.txt by deken upload. It says this:
'jpcex-v0.1-objects.txt' is not an externals archive!

What to do next? (is this file actually needed anymore?)
Do I just wait for the server side to index my package?

Thanks

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

Re: [PD] [PD-announce] deken v0.3.0: new fileformat for library packages

[Alexandre Torres Porres]

awesome!

2018-03-08 13:09 GMT-03:00 IOhannes m zmoelnig :

>
> - (optionally) show a README that is included in the package on
> successful installation
>

Can this be any file format, like a PDF? Or does it have to be .txt or
something?

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

Re: [PD] [PD-announce] deken v0.3.0: new fileformat for library packages

[IOhannes m zmoelnig]

On 2018-03-08 17:09, IOhannes m zmoelnig wrote:
> 
[...]
> # Pd-integration
> the updated "deken-plugin" has a number of nifty features, you don't
> want to miss:
> - bugfixes


by now, we are at v0.3.1, which (among other things) works around
Microsoft's insistance that zip-files *must* end with .zip.

i've retracted the v0.3.0 release...

dams
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] deken v0.3.0: new fileformat for library packages

[Roman Haefeli]

On Don, 2018-03-08 at 17:09 +0100, IOhannes m zmoelnig wrote:
> we are proud to announce a major overhaul of the deken fileformat.

[...]

> - (optionally) uninstall libraries before re-installing them

Yay!

Thanks for your work. Nice development of matters.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] deken v0.3.0: new fileformat for library packages

[Alexandre Torres Porres]

2018-03-08 17:44 GMT-03:00 Roman Haefeli :

> At the risk of not being helpful to the issue by adding another
> opinion, I disagree. Or rather: I do not really follow you.


That's quite possible, when it comes to me :/


> I don't see any problem with deken installing into a hidden folder. It's a
> pretty
> common thing on all OSs. Just a have a look at the contents of
> ~/Library, %AppData%\, ~/.local/ .
>

Yeah, that's not really the point. Perhaps this needs yet more
contextualization. The idea that deken should create non existing (but
needed/relevant) folders is old. It comes from a resistance that Pd should
create such folders automatically, so, as a solution, you could do that
inside Deken, and Pd wouldn't impose the creation of such folders.

A further aggravating factor is that one of such supposedly needed/relevant
folders, in macOS, became hidden since 10.6, and this would be "
~/Library/Pd". So it became quite inconvenient and counterproductive, so we
needed a better default place to keep externals.

Now, well, does Pd have files somewhere inside ~/Library? Yeah, but where?
In ~/Library/Preferences. Does Pd need a "Pd" folder inside ~/Library for
its documents? No, to the extent that Pd doesn't even create a folder there
on its own there...

And do we need Pd documents and externals in hidden places? Does it have
any advantage? No, it doesn't. And in fact, such folder wasn't chosen
because it was hidden. It became hidden and inconvenient. It's not that
having a hidden folder for externals in macOS was intended by design and
principle in the first place.


> You say: "Newbies have troubles finding the folder"
>
> I say: "Newbies shouldn't have to know about it all"
>

What is the advantage of keeping externals in a hidden folder so people can
not even have a look at it and browse through them?

Ideally (in my notion of how things would ideally be), there is nothing
> to be done manually in that folder. Ideally, deken is a management
> interface  for the user to install, enable, disable, remove libraries.
>

But it doesn't do all that, for instance, it doesn't delete/remove
libraries. And maybe it doesn't have to. Why does it have to do everything,
if there are many things you can easily do manually, like  a simple thing
such as delete a folder. What would be the advantage of hiding it and
having a framework to do it for you?

And if you want to have a hidden folder if you wish, you can. Just
configure Pd and deken to use a hidden folder of your choice. It's just
that there is nothing special about ~/Library/Pd, it's quite arbitrary...

And anyway, what came out of an old discussion is that we should indeed
have a new and visible folder for externals. Hence ~/Documents/Pd, a
visible and easily accessible folder, instead of ~/Library/Pd, an
inconvenient hidden one. Again, this solved all the issues. We've been
through all that before. Same concern about Pd not adding ~/Documents/Pd
automatically was solved by now prompting the user when it is first
launched, and then creates it for you.

So why are we giving this step back? Why are we concerned in making it
easier to manage that hidden folder that Pd doesn't create for you? What is
special about it? If we're going for friendliness, my point was not that we
should avoid, by principle, hidden folders, it was just that this had
already been sorted and we do have a new, better, and user friendly
procedure since 0.48-0! Doing this now only adds up complexity and
confusion, and it isn't even a full solution. Ok, so now you can at least
create the folder, but how can you access it? If we're going to that
direction, maybe deken should open that folder too for us...

There's no point in trying to fix something that has been already fixed
again in a different way. And please understand that I was one that was
asking for such a deken feature in the first place, it's just that things
have changed and we already have a different outcome.

Unless... unless such a folder is indeed needed and special by design. But
it isn't. We've also been through that. I also thought it was supposed to
be special, namely an additional "standard path", and that Pd needed and
had such standard paths, but it turns out it doesn't! the "standard path"
should be only one, the "extra" folder.

So there's really nothing about this that makes sense, as I see it. This is
just an ugly kludge, this is just more noise into the system.

You would install a library and this is enables you to simply do [declare
> -std[path|lib] yourlib] to use it in your patch.


You're using the "-std" prefix, giving the idea we should install in
"standard path", and this is also a confusing topic. We shouldn't, we can
pretty much, and should, just use -path and -lib.


> It looks like we're getting closer to that with all the efforts done
> recently.
>

Yes we are, and I don't wanna sound negative, I'm really glad and excited
with all the developments. Like I said before, I consider 

Re: [PD] [PD-announce] deken v0.3.0: new fileformat for library packages

[Alexandre Torres Porres]

2018-03-08 14:27 GMT-03:00 Alexandre Torres Porres :
>
>
> Now, I don't know how the plugin works, but I may assume it gets these
> paths from Pd, so maybe if my Pull Request gets accepted, no change needs
> to be made in the Deken plugin and it'll just stop showing them...
>

Yes, that is correct, I tried the Pull Request with the new plugin and it
just didn't prompt me for these additional standard paths, so this can be
discussed completely in parallel. And by the way, I closed the old one and
have a new Pull Request for that -
https://github.com/pure-data/pure-data/pull/321

cheers and congratulations again for the great work on Deken
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] deken v0.3.0: new fileformat for library packages

[IOhannes m zmoelnig]

we are proud to announce a major overhaul of the deken fileformat.

TL;DR to download new deken packages, you will need at least version
v0.3.0 of the deken-plugin (Pd-0.48-1 includes deken-v0.2.4).
When searching externals with an old (incompatible) version of the
plugin, you will always find a suggestion to install the new plugin with
something like:

> deken-plugin/0.3.0
>  (Deken externals downloader - REQUIRED FOR NEW PACKAGES)

once you have installed the new version (and/or Pd includes a compatible
version), the nagging will stop :-)


# fileformat

the new fileformat fixes a number of issues we had with the existing one.
things that are better:
- cool filename extension '.dek'
- consistent archival options for all platforms (ZIP!)
- proper detection of the version string for all libraries (even if the
library has a weird name like "a-v12"
- support for double-precision externals (once Pd supports that!)
- extensible


# Pd-integration
the updated "deken-plugin" has a number of nifty features, you don't
want to miss:
- support for the new fileformat
- support for the old (legacy) fileformat
- (optionally) uninstall libraries before re-installing them
- (optionally) show a README that is included in the package on
successful installation
- set installation path (suggesting Pd's default search paths, and
offering to create those that are missing)
- (optionally) hides the search-results for incompatible platforms
- (optionally) overrides the "compatible" Pd-architecture
- nice preferences
- bugfixes
- much more


# Developer tools
if you are a developer of libraries, we have also updated our 'deken'
cmdline tool.
things you always wanted to have and which are now free:
- support for the new fileformat (default)
- support for the old (legacy) fileformat
- better detection of binary architectures
- better detection of included sources
- (experimental) support for double-precision externals
- pre-compiled & self-contained Windows binaries
- bugfixes
- much more


if you want to know more, see
- http://puredata.info/downloads/deken/releases/0.3.0/
- https://lists.puredata.info/pipermail/pd-dev/2018-02/021513.html
- https://github.com/pure-data/deken/issues/161


i have submitted also submitted a Pull-Request to include the new
deken-plugin into Pd proper:
- https://github.com/pure-data/pure-data/pull/320

and another Pull-Request for Pd that is required to make the
double-precision detection work:
- https://github.com/pure-data/pure-data/pull/300


happy patching.
fgm,asdr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
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