[PD] syncronize midi cc send
Hi everybody! I'm new to this mailing list, and I am also a new PD user. I use PD in order to send MIDI messages to the AudioMulch software, with wich I play live. (techno based music) Ok, my question is: is it possible to syncronize the midi messages I send from PD to AM? for example, I would like to trigger AM patterns with a PD patch in an Ableton Live style, so that the midi message is effectively sent by PD only at the beginning -let say- of the next bar (or 1/2, 1/4, etc etc..).. is it possible? wich object do I have to use? Thanks, and sorry for my bad english, I hope it's almost understandable! Regards, Daniele F, Italy ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] syncronize midi cc send
I think Audio Mulch responds to simple note-ons doesn't it? Try using [1( | [metro 500] | [42( | [makenote 127 499] | | [noteout] That sends on all midi channels afaik If you need to change channel - last inlet of noteout On Thu, 14 Dec 2006 16:42:54 +0100 Daniele F. [EMAIL PROTECTED] wrote: Hi everybody! I'm new to this mailing list, and I am also a new PD user. I use PD in order to send MIDI messages to the AudioMulch software, with wich I play live. (techno based music) Ok, my question is: is it possible to syncronize the midi messages I send from PD to AM? for example, I would like to trigger AM patterns with a PD patch in an Ableton Live style, so that the midi message is effectively sent by PD only at the beginning -let say- of the next bar (or 1/2, 1/4, etc etc..).. is it possible? wich object do I have to use? Thanks, and sorry for my bad english, I hope it's almost understandable! Regards, Daniele F, Italy ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] syncronize midi cc send
Sorry, no coffee yet. I didn't see the noob bit, welcome to the puredat list - that diagram is probably very confusing. What it means is a way of showing a Pd patch - The first object is a message box containing 1, that gets sent to the metronome which switches it on (0 switches it off), which sends regular pulses to the [makenote] the first value in makenote is the velocity/loudness the second is the duration in milliseconds, which is set to one less than the repeat period of the metro The last value in noteout is the midi note number (that's the one you will have to choose to match the pattern you want to trigger in AM so maybe connect a number box up to that On Thu, 14 Dec 2006 16:42:54 +0100 Daniele F. [EMAIL PROTECTED] wrote: Hi everybody! I'm new to this mailing list, and I am also a new PD user. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] netpd-shuffle: the netpd-radio
hi mark
quite a few applications are involved:
-a bash-scripts (wget, sed, etc.) creates a actual playlist (m3u) from
the apache-directory-list
-mplayer is started with '-input file=fifo'-flag and plays the
m3u-file in shuffle mode. trough the fifo it can be controled by any
other application
-mplayer connects itself with puredata over the jack-server.
-a puredata-patch converts the audio into a mp3-stream using the
[mp3cast~]-object from y.degoyon's unauthorized. it's maybe not too
straight forward to go over pd for that purpose, but i like to have the
opportunity to process the stream (gain-control [which i plan to
implement], add jingles or whatever)
-an icecast-server receives the mp3-stream from pd
-a little php-script sends the appropriate command to the fifo, that is
read by mplayer, when the button on the webpage is clicked.
roman
On Fri, 2006-12-15 at 06:19 -0800, mark edward grimm wrote:
hey roman,
just curious what software you used for the streaming
radio... icecast or something to that effect?
BTW. the shuffle option is pretty cool:)
cheers
mark
--- Roman Haefeli [EMAIL PROTECTED] wrote:
hi all
netpd-shuffle, the netpd-radio-stream, plays just
everything that ever
has been recorded from netpd-sessions. there is also
an
ANTI_BOREDOM_BUTTON on it's webinterface, that is to
press, when a
session lasts for a too long time and is going to
become boring (some
sessions are more than an hour long and stay the
same for some time,
because everyone is chatting instead of making
music ;-)
http://www.netpd.org/listen
--this is all stuff made purely with puredata--
on the same stream livesessions will be broadcasted,
that hopefully will
happen every thursday @ 9pm GMT. everyone is kindly
invited to
participate.
cheers
roman
___
Telefonate ohne weitere Kosten vom PC zum PC:
http://messenger.yahoo.de
___
PD-announce mailing list
[EMAIL PROTECTED]
http://lists.puredata.info/listinfo/pd-announce
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
mark edward grimm | m.f.a | ed.m
megrimm.net | socialmediagroup.org .com
[EMAIL PROTECTED] | 585.509.8703
__
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstraction [define]
I've been thinking about some other ways to do that (also would like to figure out how to bundle externs, files for 'qlist', etc in a single gesture) but there's something about this particular idea I like... (OK here are some others: 2. Have a bundle file type that causes Pd actually to build a directory for a patch to run in complete with any other files needed 3. fix file reading so that the Pd file format can pre-define nonexistent file pathnames that binbuf_read and sys_load_lib, etc. would check for and pretend were there 4. write a general state-saving mechanism of some sort ) Anyway, there's something elegant about the pddefine mechanism - if I could just generalize it to cover at least some of the other situations I'd do it right away :) thanks Miller On Thu, Dec 14, 2006 at 10:29:53PM -0700, Luke Iannini (pd) wrote: I just thought I'd propose an idea I had driving home : ): As a supplement to the subpatcher functionality, what about having a [pddefine] object that took a name as its argument, and a patch built inside would then be callable within the parent patch patch, acting functionally equivalent to an abstraction (i.e. arguments, etc). The advantage of this would to simplify distribution of pd-patches that would like to use abstractions, but don't want to have to include 15 files for one program. It would also be great for 1-off abstractions that aren't usable elsewhere, but are needed multiple times in the same patch. Anyhow, I can't write it, so I guess it's just an idea for able devs to consider. Luke ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstraction [define]
Did I have too much wax in my ears, or did I just hear Miller say something about integrating a state saving system in Pd!?!?! Is it April 1st? Please do this! It would make my decade. ~Kyle On 12/15/06, Miller Puckette [EMAIL PROTECTED] wrote: 4. write a general state-saving mechanism of some sort thanks Miller -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstraction [define]
On Dec 15, 2006, at 12:16 PM, Miller Puckette wrote: I've been thinking about some other ways to do that (also would like to figure out how to bundle externs, files for 'qlist', etc in a single gesture) but there's something about this particular idea I like... (OK here are some others: 2. Have a bundle file type that causes Pd actually to build a directory for a patch to run in complete with any other files needed This bundle could be easily the same format as the libdir. We'd just need a way to create them from within the Pd GUI. Right now, in the folder mylib, there is mylib-meta.pd. The presence of this file marks the folder as a libdir. In the not-to-distant future, this file will be parsed for requirements for that library, like whether it needs a python, CLR, etc. loader; the author, license, and description of the library, and so on and so forth. One question is whether this should be in a .jar-like compressed tarball or not. .hc 3. fix file reading so that the Pd file format can pre-define nonexistent file pathnames that binbuf_read and sys_load_lib, etc. would check for and pretend were there 4. write a general state-saving mechanism of some sort ) Anyway, there's something elegant about the pddefine mechanism - if I could just generalize it to cover at least some of the other situations I'd do it right away :) thanks Miller On Thu, Dec 14, 2006 at 10:29:53PM -0700, Luke Iannini (pd) wrote: I just thought I'd propose an idea I had driving home : ): As a supplement to the subpatcher functionality, what about having a [pddefine] object that took a name as its argument, and a patch built inside would then be callable within the parent patch patch, acting functionally equivalent to an abstraction (i.e. arguments, etc). The advantage of this would to simplify distribution of pd-patches that would like to use abstractions, but don't want to have to include 15 files for one program. It would also be great for 1-off abstractions that aren't usable elsewhere, but are needed multiple times in the same patch. Anyhow, I can't write it, so I guess it's just an idea for able devs to consider. Luke ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstraction [define]
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: I've been thinking about some other ways to do that (also would like to figure out how to bundle externs, files for 'qlist', etc in a single gesture) but there's something about this particular idea I like... (OK here are some others: 2. Have a bundle file type that causes Pd actually to build a directory for a patch to run in complete with any other files needed That would actually be a wonderful thing to have. Personally I don't care about really embedding abstractions into a patch, they can stay seperate files as far as I'm concerned. Any major application today consists of lots of different files and not just one executable, too. However with a growing number of abstractions I built and use all the time, it's becoming a bit hard to 1) share the patches with others and 2) make a kind of snapshot of a project complete with all abstractions used, for example to do easy backups. A Save as bundle would solve both problems. A bundle could just be a directory, optionally (t)archived into a single file (but please only optionally: I'd want to store bundles in a versioning system. 4. write a general state-saving mechanism of some sort That's of course the part that's a little bit tricky. A good start IMO would be to include the power of something like [OSCroute] into Pd to easily access state variable hidden deep inside abstraction trees, preferably with wildcards (like: /*/slider_[abc] 127) and to have a dictionary- or map-like data type to quickly store and restore values by the name of a key instead of having to walk through a list as in textfile. A further step would be some easy way to read and write the state of objects without having to watch their communication through senders and receivers, but that's the hard part, because it touches philosophical questions like: What actually is a state? ;) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstraction [define]
On Dec 15, 2006, at 5:14 PM, Frank Barknecht wrote: Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: I've been thinking about some other ways to do that (also would like to figure out how to bundle externs, files for 'qlist', etc in a single gesture) but there's something about this particular idea I like... (OK here are some others: 2. Have a bundle file type that causes Pd actually to build a directory for a patch to run in complete with any other files needed That would actually be a wonderful thing to have. Personally I don't care about really embedding abstractions into a patch, they can stay seperate files as far as I'm concerned. Any major application today consists of lots of different files and not just one executable, too. However with a growing number of abstractions I built and use all the time, it's becoming a bit hard to 1) share the patches with others and 2) make a kind of snapshot of a project complete with all abstractions used, for example to do easy backups. A Save as bundle would solve both problems. A bundle could just be a directory, optionally (t)archived into a single file (but please only optionally: I'd want to store bundles in a versioning system. From what I gather you are looking for, a libdir is almost ready for that. AFAIK, the only missing piece is a mechanism to open a libdir like a patch. I think this could be done in the mybundle-meta.pd file. If Pd loaded that file when it opens a libdir, then you could add a tiny bit of code into it to load any other patch you might want. Something like: [loadbang] | [; pd open mypatch.pd( 4. write a general state-saving mechanism of some sort That's of course the part that's a little bit tricky. A good start IMO would be to include the power of something like [OSCroute] into Pd to easily access state variable hidden deep inside abstraction trees, preferably with wildcards (like: /*/slider_[abc] 127) and to have a dictionary- or map-like data type to quickly store and restore values by the name of a key instead of having to walk through a list as in textfile. A further step would be some easy way to read and write the state of objects without having to watch their communication through senders and receivers, but that's the hard part, because it touches philosophical questions like: What actually is a state? ;) I am a big fan of the way that you have done it, Frank, using only existing objects. I think to make the whole thing complete, there should be a set of GOP GUI objects with your state saving stuff inside. Then people just use those GOP objects if they want state- saving. This gives me an idea of where having the IEMGUI separate would be handy: if you have a set of GUIs all named the same as the IEMGUIs, then you could add state-saving to a patch just by changing [import iemgui] to [import sssadgui]. Then [hslider] would change from [iemgui/hsl] to [sssadgui/hsl] .hc Access to computers should be unlimited and total. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstraction [define]
On Dec 15, 2006, at 5:44 PM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: From what I gather you are looking for, a libdir is almost ready for that. AFAIK, the only missing piece is a mechanism to open a libdir like a patch. I think this could be done in the mybundle-meta.pd file. If Pd loaded that file when it opens a libdir, then you could add a tiny bit of code into it to load any other patch you might want. Something like: [loadbang] | [; pd open mypatch.pd( Actually I think opening isn't such a problem, saving as bundle however is. If I have lots of abstractions in different (lib)dirs, then currently I'd need to search then by hand. I get it, so it would be like a Save As Bundle.. option in the File menu which would then save everything needed to make it work into one bundle. One tricky thing would be determining which should be included. In the context of Pd-extended, should this save abstractions that come with Pd-extended into the bundle? Or just ones external to Pd-extended? That could get into issues with versioning. I suppose this could be viewed as the compiled app for Pd. So it would include all objects in the Bundle, including binary files (.dll, .pd_*). Then it new versions of any of the dependencies wouldn't break patch in the bundle, since the bundle would have all the static versions. It would basically be like static linking for a Pd patch. I am a big fan of the way that you have done it, Frank, using only existing objects. I think to make the whole thing complete, there should be a set of GOP GUI objects with your state saving stuff inside. Then people just use those GOP objects if they want state- saving. Chris McCormick's collection has some of these. (I also have but they aren't published yet because I'm lazy...) That would be a very useful library to have, poke poke. :) .hc Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
