[PD] troubles killing a pd instance with shell object

[fls]

Hi Marco,

I read the source code of this external* and it works with a fork. It
means that we have a parent process, your first PD instance, and a child
process, the shell that created your second PD instance. AFAIK it is not
possible to kill the parent process and keep the child running. The child
is the shell and your second PD instance depends on this process to run.
It's possible to run a child without a parent but [shell] should use a
nohup or something like that. Since this external doesn't seem to have it
implemented, I don't think that it will be possible.

Schiavoni

P.S.: Reading the source code I discovered that this object accept a bang
message that prints "bang". It also has an unused static variable
"shell_pid"...

*
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/ggee/control/shell.c


> Hi all,
>
> I'm having some troubles with two pd instances and [shell].
>
> I launch a patch with the first Pd instance from the terminal. Here, i use
> [shell] to create a new patch and open it with a second Pd instance.
>
> when the new patch is loaded, it sends a [quit( message to [noquit] to the
> first pd-instance patch, via OSC, in order to kill it.
>
> everything works fine until the first instance receive the OSC message. At
> this point, the pd process is killed but the GUI freezes on the screen,
> and
> the terminal freezes too.
>
> If I launch the first Pd instance from the terminal with '&', and then run
> the script through
>  the same terminal, it works fine.
>
> this below is the script. nothing fancy.
>
> any idea why the process doesn't work?
>
> thanksss!
>
>
> \\
> #!/bin/bash
>
> NEWPATCH=$1
> cp /usr/share/Xth-Sense/Xth-Sense.pd $HOME/Desktop/$NEWPATCH.pd;
> sleep 2;
> pdextended -alsa $HOME/Desktop/$NEWPATCH.pd;
> exit
> \\
>
>
>
>
> --
> Marco Donnarumma
> New Media + Sonic Arts Practitioner, Performer, Teacher, Director.
> Embodied Audio-Visual Interaction Research Team.
> Department of Computing, Goldsmiths University of London
> ~
> Portfolio: http://marcodonnarumma.com
> Research: http://res.marcodonnarumma.com
> Director: http://www.liveperformersmeeting.net
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> 


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

Re: [PD] TCP/IP communication from the unix server to the Pure Data

[fls]

First at all, you don't need to swap byte endianness just because you are
sending it to the network. You have to put in the network format just the
header data like port and IP. The network devices read the header but
don't use to touch the data section of the packet where your samples will
be.

You have to use it only if server and receiver are in different hardware
architecture.

The ntohl() converts only long integer values what means a 32 bit integer.
there is another function called ntohs() that converts short integer (16
bits). So, you can't pass a float to the function. The float structure has
a mantisse, a biased exponent and a signal. A integer doesn't. One
solution is to convert your float point to long integer, use the byte swap
function and convert back to integer. Other solution is to check if your
machine is little or big endian and create a byte swap to float manually
and do not use htonl().

Cheers

Schiavoni

> Martin , thank you for everything, I got it working now even with
> floating point numbers, here is the rundown of the method
>
> [solved]
> BUT BEFORE FOLLOWING THIS, NOTE THAT FLOATING POINT NUMBER IS SOMETHING
> THAT YOU DON'T WANT TO PARSE, IF YOU LIKE YOUR NERVES.
>
> The first problem is
> 1. Error was in using on the server side an ntohl() on a float number,
> which corrupts it heavily. Mark my words, ntohl() is an enemy of the
> float.
> Just receive it reversed and manually work out the conversion, you HAVE
> to do it manually anyways :P
>
> 2. Float is a complex standard, even more complex when Pure Data
> converts everything to decimal partially per byte. Separate Mantissa,
> Exponent and Sign using bitwise operators [<<][>>], and work out the
> float conversion.
> Follow this thread for Mantissa, that one is the hardest Convert
> floating point number from binary to a decimal number
> 
>
> Good luck ^^
>
> //Petar
>
> On 13/3/13 1:51 PM, Martin Peach wrote:
>> I attached a patch that should reconstruct a long if it's bigendian,
>> although it doesn't give 100 for the sequence you provided...
>>
>> The floating point numbers are more difficult, you need to separate
>> the sign, exponent and mantissa and then put it all together.
>>
>> Martin
>>
>> On 2013-03-13 06:08, Petar Jercic wrote:
>>> Wow, these methods you proposed made me realize that I was using the
>>> wrong endian method on my UNIX server, it has to be ntohl(). Now I got
>>> it correct, and I am receiving data (bytes) in the correct order.
>>>
>>> *>>>: 0 0 0 2 0 10 114 26 0 0 0 51 0 16 242 78
>>> *
>>> Sample data might be 2 100 51 2000.56, which could be read in the
>>> data ... somewhat :)*
>>>
>>> **Now my question is, how do I get four compact numbers to work with?*
>>> Now I have a series of bytes, but at least in the correct order.
>>>
>>> I haven't been able to extract the data using [bytes2any] and [route],
>>> so I prepared a small patch to demonstrate the problem, maybe you can
>>> show me by modifying it?
>>>
>>> //Petar
>>>
>>> On 11/3/13 2:31 PM, Martin Peach wrote:
 On 2013-03-10 17:58, Petar Jercic wrote:
> Sorry, I can't use ASCII text as communication method, since I plan
> to
> send large quantities of data at high speed rates, I need to
> optimize it
> as much as possible. Compared to streaming bytes, ASCII is
> inefficient
> up to a several orders of magnitude.
>
> Is there a method for correct endianness in Pure Data, like these C
> functions:
>
> ntohs()--"Network to Host Short"
> ntohl()--"Network to Host Long"

 You can do that with Pd like this (ntohs):

 [unpack 0 0]
 |  |
 [* 256]|
 |  |
 [+  ]
 |
 [   \

 or

 [unpack 0 0]
 |  |
 |  [* 256]
 |  |
 [+  ]
 |
 [   \

 for littleendian.

 Floats are harder but still possible. The main difficulty is in
 splitting the incoming stream in the right places. (I think ASCII is
 not orders of magnitude slower, and it is also less ambiguous).

 Martin



>
> On 09/3/13 5:15 PM, Martin Peach wrote:
>> It's probably safer to get the server to send the numbers as ASCII
>> text, to avoid disagreements about endianness and floating-point
>> representation.
>> Then, to extract the numbers, you could use [moocow/bytes2any] or
>> make
>> a custom parser using [pdlua].
>>
>> Martin
>>
>>
>> On 2013-03-09 10:55, Petar Jercic wrote:
>>> Apparently [netclient] on the Pure Data side cannot receive nothing
>>> else
>>> than ; delimited messages.
>>> So the solution for the problem:
>>> *My question is, is there a way to send something other than string
>>> message to Pure Data, like byte-stream or serialized number stream?
>>> Can

Re: [PD] Message from the boss of Raspberry Pi Foundation !

[fls]

Dear all

I know 2 works on GPU and PD. André developed something with PD and GPU.

http://www.ime.usp.br/~ajb/wiki/artigos/article-icmc2012-ajb-mqz.pdf

Chuck (Charles Henry) also developed something and he helped Andre to
develop his code.

http://www.uni-weimar.de/medien/wiki/PDCON:Conference/GPU_audio_signals_processing_in_Pd,_and_PDCUDA,_an_implementation_with_the_CUDA_runtime_API

AFAIK, there is a lib that allows you to copy the processing functions to
GPU pipeline and the data to be processed. This lib can identify if there
is a GPU available in the system and present the information about it. I
think that it really would be a good thing to DSP processing on RPI.

Bests

F Schiavoni

> @Hardoff : the patch i'm using in the video requires 16 ms of latency,
> because it uses phase vocoding. You can drop to 10 ms without it, and I
> guess even lower would be possible. I use the very first version of the
> Pi,
> with half the RAM the new model has. If we can get the GPU to compute the
> audio i hope that we'll be able to get to really reasonable latencies (to
> me 6 to 8 ms is really enough to play live). Also, i use the regular Pd
> fro
> the debian repos. I can't tell you whether Miller's or Katja's version
> work
> better.
>
> Cheers,
>
> Piere.


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

Re: [PD] online video conferencing

[fls]

Hi Eldad!

Recently we had a netmusic conference (http://netmusic2013.wordpress.com/)
and we used jacktrip for audio streams and bluejeans
(http://bluejeans.com/) to the video streams. Instead of some problems
with bluejeans, it worked.

Bests

Schiavoni

> Hi all,
> I am looking for an accessible way to do a video conference with multiple
> parties (4 or 5) for a telematic performance.
> The bandwidth is there and visual latency is not an issue in this case.
> Any ideas about a stable platform for this would be greatly appreciated.
>
> In the past I worked with Access Grid, which was quite stable, but is very
> tricky to install on Snow Leopard and doesn't work at all on Lion and
> later. It still works on Windows, but not all the parties can get a
> Windows system,
> Google Hangout should work (I haven't tested it yet) but it doesn't allow
> you, to my knowledge, to separate the video windows and reorganize them on
> the screen.
>
> There are some paid cloud-conferencing services that can work for this,
> but as far as I know they work on subscription. If you know of such a
> service that allows renting a video conferencing service temporarily that
> could be helpful too.
>
> Many thanks for any help
> Eldad


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

Re: [PD] Plugin auto install feature to Pure data

[fls]

Thanks Hans!

Just one doubt: How does it work for different architectures? Should we
pack windows, linux and Mac in different packages? Or can we include them
in one package and the installer copies just the right one?

cheers

f schiavoni

> This stuff is already pretty well defined in the library template and the
> *-meta.pd file.  I think the meta file would be the place to add things
> like
> dependencies also.
>
> http://puredata.info/docs/developer/Libdir
> http://puredata.info/docs/developer/LibraryTemplate
>
> .hc
>
> On 02/05/2013 04:11 PM, f...@rendera.com.br wrote:
>> I agree that depencencies should not install libs. Since it seems to be
>> the biggest problem, maybe it should be postponed.
>>
>> Yes, the repository maintenance can be solved latter too. Let's first
>> have
>> a repository and then think about the best way to keep it on date. :-)
>>
>> I don't have skills with TCL but I agree that it is a good choice. Is
>> there how to open zip/tar/something files in TCL? If it can open the
>> package, it's perfect.
>>
>> IMO, the first step is to install locally. Define a package structure, a
>> package header and the install script. Probably it can be used by the
>> remote install.
>>
>> I suggest the following package structure:
>> /content.txt
>> /bin/files <-to compiled files (architecture dependent)
>> /help/files <-to help files (architecture independent)
>> /tcl/files <-to gui files (architecture independent)
>>
>> This structure should be compacted / grouped in a file with some name
>> convention like package_name.version.pd_pkg.
>>
>> The content.txt can be as follow:
>> name:
>> author:
>> version:
>> key-words:
>> web-site:
>> license:
>> flavor:
>> dependencies:
>> instructions:
>>
>> The install script should select a package, open it, copy the external
>> to
>> the external dir, copy the help and tcl files to the correct folder,
>> rename the content.txt to the package name + version and copy it to an
>> folder designed for this kind of file.
>>
>> Cheers
>>
>> f schiavoni


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

Re: [PD] Plugin auto install feature to Pure data

[fls]

I agree that depencencies should not install libs. Since it seems to be
the biggest problem, maybe it should be postponed.

Yes, the repository maintenance can be solved latter too. Let's first have
a repository and then think about the best way to keep it on date. :-)

I don't have skills with TCL but I agree that it is a good choice. Is
there how to open zip/tar/something files in TCL? If it can open the
package, it's perfect.

IMO, the first step is to install locally. Define a package structure, a
package header and the install script. Probably it can be used by the
remote install.

I suggest the following package structure:
/content.txt
/bin/files <-to compiled files (architecture dependent)
/help/files <-to help files (architecture independent)
/tcl/files <-to gui files (architecture independent)

This structure should be compacted / grouped in a file with some name
convention like package_name.version.pd_pkg.

The content.txt can be as follow:
name:
author:
version:
key-words:
web-site:
license:
flavor:
dependencies:
instructions:

The install script should select a package, open it, copy the external to
the external dir, copy the help and tcl files to the correct folder,
rename the content.txt to the package name + version and copy it to an
folder designed for this kind of file.

Cheers

f schiavoni


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

Re: [PD] [Spam] RE : Re: RE : Plugin auto install feature to Pure data

[fls]

Hi Colet

I don't think so. We can think about several servers (repositories) that
the user can choose. So pd-extended can have an official repository and I
can have mine.

f schiavoni

> Wget and tar could be replaced with TCL http and tar module at client
> side, and for server side I'd use PHP and mySQL, or maybe python instead
> of PHP... One thing I'm wondering is how to share packages between several
> servers, would all http servers need a build farm?
>
>  Message d'origine 
> De : f...@rendera.com.br
> Date : 04/02/2013  17:57  (GMT+00:00)
> A : pd-list@iem.at,"colet.patrice" 
> Objet : Re: RE : [PD] Plugin auto install feature to Pure data
>
> I'm not used with TCL Tk but my guess it that it should be enough. In
> linux wget + tar + shell script can solve it. I don't know how portable is
> a solution like this.
>
> The PHP + SQL was just a suggestion of a tool to update the repository.
> Nothing about PD.
>
> About the dependencies, if the external uses only the ANSI C API, it will
> not be a problem. It is more confuse if it uses some special lib that
> should be installed with the external. As I would not like to install
> automatically a new library in my machine, I think the plugin descriptor
> can has a field called instruction where the author can specify how to
> install the dependencies. And that's it.
>
> cheers
>
> f schiavoni
>
>
>> Hello, that's a quite interesting subject I've been thinking about for
>> pdx
>> since a time, thank you for the contribution... like you said it
>> might be
>> complicated to resolve all dependences required by an external, so I
>> think
>> that adding other dependences like php sql or json would make it even
>> more
>> complicated... Why not just using the native client interpreted langage,
>> TCL-TK? With the help of a command line like wget included with the tcl
>> script and a bunch of pkg files that should be enough, wouldn't it?
>>
>>
>>
>>
>>
>>
>>  Message d'origine 
>> De : f...@rendera.com.br
>> Date : 03/02/2013  20:22  (GMT+00:00)
>> A : pd-list@iem.at
>> Objet : [PD] Plugin auto install feature to Pure data
>>
>> Hi list
>>
>> I would like to write before but unfortunately I couldn't. Some weeks
>> ago
>> people started to talk about the development of some auto install
>> mechanism to Pure Data, like the apt-get. It is an amazing idea. I
>> researched and developed some thing like it to my master degree and I
>> would like to contrib with my 3 cents.
>>
>> I studied the plugin structure of Netbeans, Eclipse, Fire Fox, deb and
>> rpm
>> and my contribution is about it. Sorry if I am a little bit prolix.
>>
>> The first thing is to create a plugin package. A a single file to group
>> a
>> lot of files. It can be a zip package, tar, gzip or anything that
>> already
>> has some C open source API to pack / unpack. This way we can upload /
>> download a single file and extract it localy. I will call it the
>> package.
>>
>> Inside the package is necessary to have a package descriptor. It can be
>> a
>> XML file, CSV, txt, JSON or any kind of structured file to describe the
>> content of the package. This file should have the information about the
>> plugin like the author, version, website, license, OS, dependencies,
>> compatibility with PD "flavors" (vanilla, extended, Lork ),
>> pre-installation script, post-installation script, uninstall script, key
>> words, ...
>>
>> Pre and post installation script are used to create SQL tables, files or
>> other things. Maybe it is not useful in PD. Uninstall script should
>> clean
>> the mess if you want to remove a plugin. Dependencies is a complex
>> problem
>> because it should care about libraries and circular dependencies. Maybe
>> it
>> is the hardest problem to solve.
>>
>> These two things will define the PD plugin: The package file and the
>> plugin descriptor inside the package. The package structure should be
>> defined as a standard. So we should agree, for example, about the name
>> of
>> the descriptor, the folder where the plugin will be and the name of the
>> package file. Probably a package file can be the name of the
>> external.version.something.pd_pkg.
>>
>> In PD we should have a list of installed plugins. It can be a directory
>> with all the plugin descriptors. The user might be able to install new
>> plugins manually. It means a local file in my machine that I choose. PD
>> will open the package, copy the content to the correct folders and copy
>> the descriptor the the correct folder. The uninstall option will do the
>> oposite, delete the plugin descriptor and delete the plugin files.
>>
>> To update from the web, a plugin repository need to be defined. The
>> client
>> should have a list of repositories address. (It is good because
>> different
>> flavors can have their own plugin repositories and the users can choose
>> which one they want to use.)
>>
>> The plugin server can be implemented with a HTTP server. It will publish
>> the list o

Re: [PD] RE : Plugin auto install feature to Pure data

[fls]

I'm not used with TCL Tk but my guess it that it should be enough. In
linux wget + tar + shell script can solve it. I don't know how portable is
a solution like this.

The PHP + SQL was just a suggestion of a tool to update the repository.
Nothing about PD.

About the dependencies, if the external uses only the ANSI C API, it will
not be a problem. It is more confuse if it uses some special lib that
should be installed with the external. As I would not like to install
automatically a new library in my machine, I think the plugin descriptor
can has a field called instruction where the author can specify how to
install the dependencies. And that's it.

cheers

f schiavoni


> Hello, that's a quite interesting subject I've been thinking about for pdx
> since a time, thank you for the contribution... like you said it might be
> complicated to resolve all dependences required by an external, so I think
> that adding other dependences like php sql or json would make it even more
> complicated... Why not just using the native client interpreted langage,
> TCL-TK? With the help of a command line like wget included with the tcl
> script and a bunch of pkg files that should be enough, wouldn't it?
>
>
>
>
>
>
>  Message d'origine 
> De : f...@rendera.com.br
> Date : 03/02/2013  20:22  (GMT+00:00)
> A : pd-list@iem.at
> Objet : [PD] Plugin auto install feature to Pure data
>
> Hi list
>
> I would like to write before but unfortunately I couldn't. Some weeks ago
> people started to talk about the development of some auto install
> mechanism to Pure Data, like the apt-get. It is an amazing idea. I
> researched and developed some thing like it to my master degree and I
> would like to contrib with my 3 cents.
>
> I studied the plugin structure of Netbeans, Eclipse, Fire Fox, deb and rpm
> and my contribution is about it. Sorry if I am a little bit prolix.
>
> The first thing is to create a plugin package. A a single file to group a
> lot of files. It can be a zip package, tar, gzip or anything that already
> has some C open source API to pack / unpack. This way we can upload /
> download a single file and extract it localy. I will call it the package.
>
> Inside the package is necessary to have a package descriptor. It can be a
> XML file, CSV, txt, JSON or any kind of structured file to describe the
> content of the package. This file should have the information about the
> plugin like the author, version, website, license, OS, dependencies,
> compatibility with PD "flavors" (vanilla, extended, Lork ),
> pre-installation script, post-installation script, uninstall script, key
> words, ...
>
> Pre and post installation script are used to create SQL tables, files or
> other things. Maybe it is not useful in PD. Uninstall script should clean
> the mess if you want to remove a plugin. Dependencies is a complex problem
> because it should care about libraries and circular dependencies. Maybe it
> is the hardest problem to solve.
>
> These two things will define the PD plugin: The package file and the
> plugin descriptor inside the package. The package structure should be
> defined as a standard. So we should agree, for example, about the name of
> the descriptor, the folder where the plugin will be and the name of the
> package file. Probably a package file can be the name of the
> external.version.something.pd_pkg.
>
> In PD we should have a list of installed plugins. It can be a directory
> with all the plugin descriptors. The user might be able to install new
> plugins manually. It means a local file in my machine that I choose. PD
> will open the package, copy the content to the correct folders and copy
> the descriptor the the correct folder. The uninstall option will do the
> oposite, delete the plugin descriptor and delete the plugin files.
>
> To update from the web, a plugin repository need to be defined. The client
> should have a list of repositories address. (It is good because different
> flavors can have their own plugin repositories and the users can choose
> which one they want to use.)
>
> The plugin server can be implemented with a HTTP server. It will publish
> the list of available plugins on the server. This list can be the list of
> package descriptors in a tar / zip file. Locally, PD will keep these
> lists, one for each server, and it will be used to look for new plugins.
> Add a new server means add the server to the repositories list and
> download the plugin list of the new server.
>
> Since PD has a list of local installed plugins, if you want to check for
> updates PD compares the servers plugin lists with your local list. Easy
> task. Different versions should can be shown and the user would be able to
> choose what to update. These descriptors can be useful also to search for
> plugins by author, version, key words, versions, ...
>
> Update a plugin means to create a list of update, download the packages to
> a temp directory and install them locally.
>
> Just to step fowa

[PD] Plugin auto install feature to Pure data

[fls]

Hi list

I would like to write before but unfortunately I couldn't. Some weeks ago
people started to talk about the development of some auto install
mechanism to Pure Data, like the apt-get. It is an amazing idea. I
researched and developed some thing like it to my master degree and I
would like to contrib with my 3 cents.

I studied the plugin structure of Netbeans, Eclipse, Fire Fox, deb and rpm
and my contribution is about it. Sorry if I am a little bit prolix.

The first thing is to create a plugin package. A a single file to group a
lot of files. It can be a zip package, tar, gzip or anything that already
has some C open source API to pack / unpack. This way we can upload /
download a single file and extract it localy. I will call it the package.

Inside the package is necessary to have a package descriptor. It can be a
XML file, CSV, txt, JSON or any kind of structured file to describe the
content of the package. This file should have the information about the
plugin like the author, version, website, license, OS, dependencies,
compatibility with PD "flavors" (vanilla, extended, Lork ),
pre-installation script, post-installation script, uninstall script, key
words, ...

Pre and post installation script are used to create SQL tables, files or
other things. Maybe it is not useful in PD. Uninstall script should clean
the mess if you want to remove a plugin. Dependencies is a complex problem
because it should care about libraries and circular dependencies. Maybe it
is the hardest problem to solve.

These two things will define the PD plugin: The package file and the
plugin descriptor inside the package. The package structure should be
defined as a standard. So we should agree, for example, about the name of
the descriptor, the folder where the plugin will be and the name of the
package file. Probably a package file can be the name of the
external.version.something.pd_pkg.

In PD we should have a list of installed plugins. It can be a directory
with all the plugin descriptors. The user might be able to install new
plugins manually. It means a local file in my machine that I choose. PD
will open the package, copy the content to the correct folders and copy
the descriptor the the correct folder. The uninstall option will do the
oposite, delete the plugin descriptor and delete the plugin files.

To update from the web, a plugin repository need to be defined. The client
should have a list of repositories address. (It is good because different
flavors can have their own plugin repositories and the users can choose
which one they want to use.)

The plugin server can be implemented with a HTTP server. It will publish
the list of available plugins on the server. This list can be the list of
package descriptors in a tar / zip file. Locally, PD will keep these
lists, one for each server, and it will be used to look for new plugins.
Add a new server means add the server to the repositories list and
download the plugin list of the new server.

Since PD has a list of local installed plugins, if you want to check for
updates PD compares the servers plugin lists with your local list. Easy
task. Different versions should can be shown and the user would be able to
choose what to update. These descriptors can be useful also to search for
plugins by author, version, key words, versions, ...

Update a plugin means to create a list of update, download the packages to
a temp directory and install them locally.

Just to step foward, the server can have a web interface with some PHP
programming, for instance, that automatically update a package, extract
the descriptor, put it in the correct folder and put the plugins in the
correct folder. Just to be easier to maintenance.

Another tool can help developers to pack. Since I did a new plugin I can
select the folder, fill a form with the meta-data and the tool will create
the package automatically.

That's it. Sorry if I wrote too much.

cheers

f schiavoni


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

[PD] LIVE STREAMING TOMORROW - Net-Music 2013: The Internet as Creative Resource in Music

[fls]

Net-Music 2013: The Internet as Creative Resource in Music

International Multi-Site Telematic Symposium

Live online streaming of the symposium will be available during the event.

This jointly organized conference will serve as a brainstorming session
for identifying future research and creative activities involving the
Internet as a primary creative medium in music. It will serve as a forum
for bringing together artists, technologists, and researchers who are
actively involved in individual and collaborative projects over the
Internet for music performance and composition. In particular we are
interested to explore areas of creative activity that make inherent use of
the Internet and related technologies for unique music composition and
performance works.

Featured speakers/presenters:

Pauline Oliveros, Department of the Arts, Rensselaer Polytechnic Institute

Chris Chafe, Center for Computer Research in Music and Acoustics, Stanford
University

This symposium is sponsored by the Yong Siew Toh Conservatory of Music of
the National University of Singapore and the Peabody Institute of the
Johns Hopkins University as part of their joint operating agreement in
conjunction with the other sponsoring partner organizations.

Sponsoring partner organizations:

Yong Siew Toh Conservatory of Music (YSTCM), National University of Singapore
The Peabody Institute of The Johns Hopkins University, Baltimore MD
Center for Computer Research in Music and Acoustics (CCRMA), Stanford
University, Stanford CA
Department of the Arts, Rensselaer Polytechnic Institute (RPI), Troy NY
Schulich School of Music, McGill University, Montreal
School of Creative and Performing Arts, Humber College, Toronto

Additional participating site:

Sonic Arts Research Centre (SARC), School of Creative Arts, Queen’s
University Belfast

More information: http://netmusic2013.wordpress.com/

Live streaming:
http://netmusic2013.wordpress.com/remote-participation-live-streaming-twitter/

Flávio Schiavoni


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

Re: [PD] array modification, segmented lines

[fls]

> Dear all,
>
> Are there any messages to draw functions of segmented lines (ideally with
> different types of interpolations) inside an array? Or does one need to
> create this manually by writing each array index?
>
> So I would like to be able to define segments by providing lists of
> start_position, segment_length, end_position.
>
> Many Thanks
> Peiman

Hi Peiman and all

Recently a friend asked me something like this. The interpolation of an
array adding points / values just like tabwrite. I developed this external
to him:

http://sourceforge.net/projects/pdinterpol/

For now it is only linear interpolation but I intend to develop other
kinds soon.

Cheers

Schiavoni


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

Re: [PD] Routing MIDI on windows machines?

[fls]

> For Mac, I set up custom IAC in/out ports for PureData and use Midi
> Patchbay to connect other apps to them.
>
> On Linux, there is always aconnect & aconnectgui or, if you're using jack,
> qjackctl.
>

Mac and Linux can also use PatchAge. Good software.

http://drobilla.net/software/patchage/

Schiavoni


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