Hi
I managed to finish my first extension (even while I haven't got a clue what pd is up to:-)).
It simply transforms output from notein to legato after these simple rules: left output: the last note that was pressed. right output: 0 if no notes are pressed other wise the velocity of the first played note. If you played a monophonic hardware synth, you'll understand my poor explanation...
Now, I have a couple of questions, just to round this off:
- The makefile is the one IOhannes pointed me towards([1]), but with
PDROOT hardcoded to "/home/atte/software/pd/current/". Isn't there a more elegant way so that someone trying to build it will have to edit the makefile?
- It doesn't like to receive a bang (basically anything but float). It
doesn't really make much sense to send it a float, but would it be nicer to handle this in some way? Right now it just prints "no method for 'bang'" in the pd window...
- Feedback? I'd be happy if someone finds it even remotely useful. Any
ideas I didn't think about?
Should I put it up somewhere, for instance on my servers svn-repo?
Did I reinvent the wheel? If so, at least I learned quite alot + had
fun while doing so :-)
[1] http://pure-data.cvs.sourceforge.net/pure-data/doc/tutorials/externals-howto...
-Wall -W -Wshadow -Wstrict-prototypes -Werror
-Wno-unused -Wno-parentheses -Wno-switch LINUXLDFLAGS = -export_dynamic -shared -lc -lm LINUXINCLUDE = -I$(PDSRCDIR) %.pd_linux: %.c $(CC) $(LINUXLDFLAGS) $(LINUXCFLAGS) $(LINUXINCLUDE) -o $*.pd_linux $*.c strip --strip-unneeded $*.pd_linux # ----------------------- Mac OSX ----------------------- pd_darwin: $(TARGETS) DARWINCFLAGS = -DPD -O2 -Wall -W -Wshadow -Wstrict-prototypes
-Wno-unused -Wno-parentheses -Wno-switch DARWININCLUDE = -I$(PDSRCDIR) DARWINLDFLAGS = -bundle -undefined suppress -flat_namespace %.pd_darwin: %.c $(CC) $(DARWINCFLAGS) $(DARWININCLUDE) $(DARWINLDFLAGS) -o $*.pd_darwin $*.c # ----------------------- IRIX 5.x ----------------------- pd_irix5: $(TARGETS) SGICFLAGS5 = -o32 -DPD -DSGI -O2 SGIINCLUDE = -I$(PDSRCDIR) SGILDFLAGS = -elf -shared -rdata_shared %.pd_irix5: %.c $(CC) $(SGICFLAGS5) $(SGIINCLUDE) -o $*.o -c $*.c $(LD) $(SGILDFLAGS) -o $*.pd_irix5 $*.o rm $*.o # ----------------------- IRIX 6.x ----------------------- pd_irix6: $(TARGETS) SGICFLAGS6 = -DPD -DSGI -n32
-OPT:roundoff=3 -OPT:IEEE_arithmetic=3 -OPT:cray_ivdep=true
-Ofast=ip32 %.pd_irix6: %.c $(CC) $(SGICFLAGS6) $(SGIINCLUDE) -o $*.o -c $*.c $(LD) $(SGILDFLAGS) -o $*.pd_irix6 $*.o rm $*.o # ----------------------- NT ----------------------- dll: $(TARGETS) PDNTCFLAGS = /W3 /WX /DPD /DNT /D__WIN32__ /DMSW /nologo VC="C:\Programme\Microsoft Visual Studio\Vc98" PDNTINCLUDE = /I. /I$(PDROOT)\tcl\include /I$(PDSRCDIR)\src /I$(VC)\include PDNTLDIR = $(VC)\lib PDNTLIB = $(PDNTLDIR)\libc.lib
$(PDNTLDIR)\oldnames.lib
$(PDNTLDIR)\kernel32.lib
$(PDLIBDIR)\pd.lib %.dll: %.c cl $(PDNTCFLAGS) $(PDNTINCLUDE) /c $*.c link /dll /export:$*_setup $*.obj $(PDNTLIB) pd_nt: $(TARGETS) MINGWCFLAGS = -DPD -O2 -funroll-loops -fomit-frame-pointer
-Wall -W -Wshadow -Wstrict-prototypes -Werror
-Wno-unused -Wno-parentheses -Wno-switch -mms-bitfields MINGWLDFLAGS = -export_dynamic -shared -lm -lkernel32 -lcoldname -lcrtdll -lpd -L$(PDLIBDIR) MINGWINCLUDE = -I$(PDSRCDIR) %.pd_nt: %.c $(CC) $(MINGWLDFLAGS) $(MINGWCFLAGS) $(MINGWINCLUDE) -o $*.dll $*.c
Atte André Jensen wrote:
If you played a monophonic hardware synth, you'll understand my poor explanation...
Oh, forgot: Attached is a pd patch with two mono midi synths, one without and on with the legato external...
Hallo, Atte André Jensen hat gesagt: // Atte André Jensen wrote:
I managed to finish my first extension (even while I haven't got a clue what pd is up to:-)).
We call these things "externals" around here. ;)
It simply transforms output from notein to legato after these simple rules: left output: the last note that was pressed.
It doesn't seem to do this all the time. With some wild clicking on attached patch I can make it send a "0" to the first inlet as well, although no note 0 was ever sent. If it's in that state, also no velocity output is generate anymore.
right output: 0 if no notes are pressed other wise the velocity of the first played note. If you played a monophonic hardware synth, you'll understand my poor explanation...
One thing that IMO should accompany every Pd external is a help patch. Just make a file NAMEOFEXTERNAL-help.pd (legato-help.pd) that shows and explains what your object does, what the inlets accept and what the outlets will produce. Ideally you'd make a little example of the object in use as well. help-patches are a good way to test objects as well.
Now, I have a couple of questions, just to round this off:
- The makefile is the one IOhannes pointed me towards([1]), but with
PDROOT hardcoded to "/home/atte/software/pd/current/". Isn't there a more elegant way so that someone trying to build it will have to edit the makefile?
I didn't need to edit the Makefile at all on Linux, however I did change #include "m_pd.h" to #include <m_pd.h> (see another thread here). If m_pd.h is in a system include path, all the PDROOT stuff is unnecessary to build the class.
- It doesn't like to receive a bang (basically anything but float). It
doesn't really make much sense to send it a float, but would it be nicer to handle this in some way? Right now it just prints "no method for 'bang'" in the pd window...
That's okay: If an object is not supposed to deal with "bang" than that's how that object is supposed to be and printing the error/warning to the console is fine.
- Should I put it up somewhere, for instance on my servers svn-repo?
puredata.info would be a good place as well. Or I would volunteer to add it to the Sourceforge-CVS.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
I managed to finish my first extension (even while I haven't got a clue what pd is up to:-)).
We call these things "externals" around here. ;)
I told you I was a newbie :-)
It doesn't seem to do this all the time. With some wild clicking on attached patch I can make it send a "0" to the first inlet as well, although no note 0 was ever sent. If it's in that state, also no velocity output is generate anymore.
Hmmm. It seems it got confused when receiving a noteon for a note that was already on (so without the acompanying noteoff inbetween), something that's quite difficult to pull off with a midi keyboard. I think it handles it a little bit smarter now. Could you please run your test again, as I'm not exactly sure if I'm just lucky here?
One thing that IMO should accompany every Pd external is a help patch. Just make a file NAMEOFEXTERNAL-help.pd (legato-help.pd) that shows and explains what your object does, what the inlets accept and what the outlets will produce. Ideally you'd make a little example of the object in use as well. help-patches are a good way to test objects as well.
Ok, I changed your's a bit. Is that sufficient? Would one normally keep all documentation in the .pd file, or is a README.txt sometimes used?
I didn't need to edit the Makefile at all on Linux, however I did change #include "m_pd.h" to #include <m_pd.h> (see another thread here). If m_pd.h is in a system include path, all the PDROOT stuff is unnecessary to build the class.
Ok, changed it to #include <m_pd.h> in makefile
- It doesn't like to receive a bang <snip>
That's okay: If an object is not supposed to deal with "bang" than that's how that object is supposed to be and printing the error/warning to the console is fine.
Ok
- Should I put it up somewhere, for instance on my servers svn-repo?
puredata.info would be a good place as well. Or I would volunteer to add it to the Sourceforge-CVS.
For now it's here (the "s" at the end, is a sign of optimism): svn co svn://atte.dk/attes-pd-externals
Hallo, Atte André Jensen hat gesagt: // Atte André Jensen wrote:
Hmmm. It seems it got confused when receiving a noteon for a note that was already on (so without the acompanying noteoff inbetween), something that's quite difficult to pull off with a midi keyboard. I think it handles it a little bit smarter now. Could you please run your test again, as I'm not exactly sure if I'm just lucky here?
It doesn't do the "reset to 0" anymore, however I'm not yet sure if it is acting as it's supposed to be. At least it's not acting as the help patch explains. Quoting:
"[legato] transforms output from [notein] to legato following these simple rules: left output: the most recently pressed note. right output: 0 if no notes are pressed otherwise the velocity of the first note that was pressed."
If I press "60 60" first the output is "60 60", which is fine. If I then press "61 61" the output is "61 -" (- for no output), which is not quite what the comment says: I'd expect "61 60", so either the comment or the external is wrong. If I then press "62 62" I get "62 -", as before. But now: If I press "60 60" again, I get no output anymore although now "60" is the most recently pressed note. If I press the noteoff "60 0" I also don't get output!
Another interesting example:
In Out 60 60 60 60 61 61 61 - 60 0 - - 60 60 60 - 60 0 61 - 61 0 - 0
I can see what you're aiming for - monophony with last note hit priority and no retriggering envelopes - but your explanation doesn't seem to be consistent with that.
But anyway: It's nice to see someone working on monophonic voice policies. On my wishlist are these:
- low note priority;
- low note priority, re-trigger envelopes;
- high note priority;
- high note priority, re-trigger envelopes;
- last note hit priority;
- last note hit priority, re-trigger envelopes;
after [1].
Of course then the object name should rather be something like "monosomething" instead of "legato". ;)
One thing that IMO should accompany every Pd external is a help patch. Just make a file NAMEOFEXTERNAL-help.pd (legato-help.pd) that shows and explains what your object does, what the inlets accept and what the outlets will produce. Ideally you'd make a little example of the object in use as well. help-patches are a good way to test objects as well.
Ok, I changed your's a bit. Is that sufficient? Would one normally keep all documentation in the .pd file, or is a README.txt sometimes used?
Normally I don't bother with a README for each single object, unless something special needs to be said (like special dependencies, libraries, license etc.)
[1] http://www.symbolicsound.com/cgi-bin/bin/view/Share/MonophonicKeyPolicyDiscu...
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
It doesn't do the "reset to 0" anymore, however I'm not yet sure if it is acting as it's supposed to be. At least it's not acting as the help patch explains.
<snip> > I can see what you're aiming for - monophony with last note hit > priority and no retriggering envelopes - but your explanation doesn't > seem to be consistent with that.
Well, then my explanation is blah, because the behavior you get is exactly what I intended. From your list it's called "last note hit priority" (no retriggering of envelopes).
Does the fact that the outlets might not update in pairs seem strange? AFAICS it's a result of the no-re-triggering of envelopes...
I'll see if I can come up with a better explanation...
But anyway: It's nice to see someone working on monophonic voice policies. On my wishlist are these:
<snip> > Of course then the object name should rather be something like > "monosomething" instead of "legato". ;)
I thought about that, but AKAICT pd defaults to mono in the first place. Legato refers to the way legato playing is handled. On my micron it's not even called anything, it's simply the way the synth works in monophonic mode.
I'm not really that interested in the other modes, but I'll have a look at implementing them also, just for completeness sake. One possibility would be controlling the behavior by an inlet but also so that oyu can do [legato 0] to selet mode 0 (whatever that would mean, then)...
Normally I don't bother with a README for each single object, unless something special needs to be said (like special dependencies, libraries, license etc.)
Ok.
Frank Barknecht wrote:
<snip> > On my wishlist are these: > > * low note priority; > * low note priority, re-trigger envelopes; > * high note priority; > * high note priority, re-trigger envelopes; > * last note hit priority; > * last note hit priority, re-trigger envelopes;
They should all be supported now. [legato] only does non re-triggering, to get re-triggering, draw velocity from outlet 2 of [midiin] instead of from outlet 2 of [legato].
Please test + comment on the new help file, which hopefully is more clear now :-)
svn co svn://atte.dk/attes-pd-externals
Atte André Jensen wrote:
They should all be supported now. [legato] only does non re-triggering, to get re-triggering, draw velocity from outlet 2 of [midiin] instead of from outlet 2 of [legato].
That (of course) doesn't work. I now added a third outlet with re-triggered velocity. Sorry for the confusion .-)
svn co svn://atte.dk/attes-pd-externals
peace, love & harmony Atte
http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions
Hallo, Atte André Jensen hat gesagt: // Atte André Jensen wrote:
Frank Barknecht wrote:
<snip> > On my wishlist are these: > > * low note priority; > * low note priority, re-trigger envelopes; > * high note priority; > * high note priority, re-trigger envelopes; > * last note hit priority; > * last note hit priority, re-trigger envelopes;
They should all be supported now. [legato] only does non re-triggering, to get re-triggering, draw velocity from outlet 2 of [midiin] instead of from outlet 2 of [legato].
Please test + comment on the new help file, which hopefully is more clear now :-)
Nice. I will do an exhaustive test later/tomorrow, but I have one additional feature idea: [poly] in Pd supports a [clear(-message that may be useful for [legato] as well to reset the internal buffers.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Nice. I will do an exhaustive test later/tomorrow
Thanks!
but I have one additional feature idea: [poly] in Pd supports a [clear(-message that may be useful for [legato] as well to reset the internal buffers.
That sounds like a plan :-)
Is the clear-message a special message and what the idea behind it (pointers to the appropiate place in the doc is fine, don't wast bandwidth on a newbie)? I looked at poly-help.pd and it makes sense. Where can I see a simple example with oscillators and all?
I must admit I'm totally confused about polyphony in pd. Actually I'm confused to the point where I believed csound to be superiour in exactly this area [for the non-csounder: csound has dynamic voice allocation out-of-the-box, meaning it's the default to be able to play as many note as the cpu can bear, but only active voices are using cpu].
Where should I look to learn about polyphony handling in pd? Maybe you could even give me a quick overview of the broad perspective?
Hi,
If you can wait about one more day...I'll be posting a link to a ready-to-use polyphonic synthesizer, which uses Frank's [polypoly] object, which in turn uses [poly]. For a sneak peak, see here (the download link doesn't work yet, as I wrap up last-minute issues with the code):
http://www.pkstonemusic.com/polyWaveSynth.html
I'll try to have the download in place by tomorrow. But I wanted you to know that polyphony is now very easy and powerful in PD.
Phil Stone
Atte André Jensen wrote:
Frank Barknecht wrote:
Nice. I will do an exhaustive test later/tomorrow
Thanks!
but I have one additional feature idea: [poly] in Pd supports a [clear(-message that may be useful for [legato] as well to reset the internal buffers.
That sounds like a plan :-)
Is the clear-message a special message and what the idea behind it (pointers to the appropiate place in the doc is fine, don't wast bandwidth on a newbie)? I looked at poly-help.pd and it makes sense. Where can I see a simple example with oscillators and all?
I must admit I'm totally confused about polyphony in pd. Actually I'm confused to the point where I believed csound to be superiour in exactly this area [for the non-csounder: csound has dynamic voice allocation out-of-the-box, meaning it's the default to be able to play as many note as the cpu can bear, but only active voices are using cpu].
Where should I look to learn about polyphony handling in pd? Maybe you could even give me a quick overview of the broad perspective?
Hallo, Atte André Jensen hat gesagt: // Atte André Jensen wrote:
Where should I look to learn about polyphony handling in pd? Maybe you could even give me a quick overview of the broad perspective?
The best place is Miller's Book, chapter "Automation and voice management": http://crca.ucsd.edu/~msp/techniques/latest/book-html/node58.html
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Atte André Jensen wrote:
I managed to finish my first extension (even while I haven't got a
clue what pd is up to:-)).
And I don't even know it's called "externals" .-)
On 05/09/2007, at 11.39, Atte André Jensen wrote:
- Feedback?
It compiles fine on os x too. Not surprisingly i suppose.
- Did I reinvent the wheel?
No idea really. I'm not musically trained in the traditional sense,
hence things that relates to that I normally store in /dev/null.
But i would think it would be a fun exercise to build it in pure Pd
objects - being new to Pd and into legato especially.
This relates to your question. There is a tendency in thinking that
"objects" that can be build by using pure Pd object are better kept
build in pure Pd objects rather then coded as an external. That said,
it's not a universal truth. Taste, ease and/or speed are important
factors here.
On Thu, Sep 06, 2007 at 09:04:43PM +0200, Steffen wrote:
This relates to your question. There is a tendency in thinking that
"objects" that can be build by using pure Pd object are better kept
build in pure Pd objects rather then coded as an external. That said,
it's not a universal truth. Taste, ease and/or speed are important
factors here.
In this particular case of Andre's legato object, I see no positive reason whatsoever for it being an external. I see several positive reasons for it being an abstraction:
- Anyone who knows how to make Pd patches can modify it.
- It would run without modifications under anyone's Pd, instantly.
- Nobody would need to compile anything.
- It probably would have been quicker to make in Pd than in code.
Best,
Chris.
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
On Thu, Sep 06, 2007 at 09:04:43PM +0200, Steffen wrote:
This relates to your question. There is a tendency in thinking that
"objects" that can be build by using pure Pd object are better kept
build in pure Pd objects rather then coded as an external. That said,
it's not a universal truth. Taste, ease and/or speed are important
factors here.In this particular case of Andre's legato object, I see no positive reason whatsoever for it being an external. I see several positive reasons for it being an abstraction:
- Anyone who knows how to make Pd patches can modify it.
- It would run without modifications under anyone's Pd, instantly.
- Nobody would need to compile anything.
- It probably would have been quicker to make in Pd than in code.
Well, it's not really trivial to code the various mono-modes in Pd. It's a bit easier with [list] now, but it involves lists that constantly change their size (to buffer lists) which is something where [list] will become slow for larger lists. So an external may still be useful.
Anyway, coding it as abstraction is an interesting project. Any takers?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 2007-09-10 at 10:09 +0200, Frank Barknecht wrote:
It's a bit easier with [list] now, but it involves lists that constantly change their size (to buffer lists) which is something where [list] will become slow for larger lists. So an external may still be useful.
is speed an issue with that little mount of data, that is processed?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Mon, 2007-09-10 at 10:09 +0200, Frank Barknecht wrote:
It's a bit easier with [list] now, but it involves lists that constantly change their size (to buffer lists) which is something where [list] will become slow for larger lists. So an external may still be useful.
is speed an issue with that little mount of data, that is processed?
Not if the amount of data stays small, but as Pd objects tend to be used in unforseen ways, the amount of data may become big in other applications. For example, what if I didn't want to use legator for only 128 midi motes but for a Harry Partch scale of 43 note steps per octave? Or what if I want to use it to drive a massive granular mono synth?
Ciao
Frank Barknecht
Chris McCormick wrote:
In this particular case of Andre's legato object,
The name is Atte :-)
I see no positive reason whatsoever for it being an external. I see several positive reasons for it being an abstraction:
I made it because I needed it and I couldn't find a similar functionality.
The reason I made it as an external was:
- Being new to PD I simply couldn't figure out how to do it as an
abstraction. All the little logics involved made me feel like building a ship in a bottle with PD. In C (or any full blown language), it's quite easy.
- I wanted to try my hands on an external.
But I'm looking forward to seeing your implementation as an abstraction, it will help me understand PD more!
Thanks in advance...
Hi Atte
attached patch should do it.
mvh/Steffen Leve Poulsen
Atte André Jensen skrev:
Chris McCormick wrote:
In this particular case of Andre's legato object,
The name is Atte :-)
I see no positive reason whatsoever for it being an external. I see several positive reasons for it being an abstraction:
I made it because I needed it and I couldn't find a similar functionality.
The reason I made it as an external was:
- Being new to PD I simply couldn't figure out how to do it as an
abstraction. All the little logics involved made me feel like building a ship in a bottle with PD. In C (or any full blown language), it's quite easy.
- I wanted to try my hands on an external.
But I'm looking forward to seeing your implementation as an abstraction, it will help me understand PD more!
Thanks in advance...
#N canvas 361 0 640 675 10; #X obj 60 41 notein; #X obj 60 283 phasor~; #X obj 60 254 mtof; #X obj 60 365 *~; #X obj 78 483 dbtorms; #X obj 81 459 hsl 128 15 0 100 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 0 1; #X obj 61 311 -~ 0.5; #X obj 58 532 dac~; #X obj 59 507 *~ 1; #X obj 239 142 f; #X obj 189 82 select 0; #X obj 189 104 - 1; #X msg 232 105 1; #X obj 209 142 +; #X obj 209 182 moses 1; #X obj 60 149 stripnote; #X obj 189 294 adsr 1 5 500 50 500; #X connect 0 0 15 0; #X connect 0 1 10 0; #X connect 0 1 15 1; #X connect 1 0 6 0; #X connect 2 0 1 0; #X connect 3 0 8 0; #X connect 4 0 8 1; #X connect 5 0 4 0; #X connect 6 0 3 0; #X connect 8 0 7 0; #X connect 8 0 7 1; #X connect 9 0 13 1; #X connect 10 0 11 0; #X connect 10 1 12 0; #X connect 11 0 13 0; #X connect 12 0 13 0; #X connect 13 0 9 0; #X connect 13 0 14 0; #X connect 14 0 16 0; #X connect 15 0 2 0; #X connect 15 1 16 0; #X connect 16 0 3 1;
same as previous, but only trigger at the beginning of phrase.
Steffen Leve Poulsen
Steffen Leve Poulsen skrev:
Hi Atte
attached patch should do it.
mvh/Steffen Leve Poulsen
Atte André Jensen skrev:
But I'm looking forward to seeing your implementation as an abstraction, it will help me understand PD more!
Thanks in advance...
#N canvas 361 0 644 679 10; #X obj 60 41 notein; #X obj 60 283 phasor~; #X obj 60 254 mtof; #X obj 60 365 *~; #X obj 78 483 dbtorms; #X obj 81 459 hsl 128 15 0 100 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 0 1; #X obj 61 311 -~ 0.5; #X obj 58 532 dac~; #X obj 59 507 *~ 1; #X obj 239 142 f; #X obj 189 82 select 0; #X obj 189 104 - 1; #X msg 232 105 1; #X obj 209 142 +; #X obj 209 182 moses 1; #X obj 60 149 stripnote; #X obj 189 294 adsr 1 5 500 50 500; #N canvas 0 0 454 304 once 0; #X obj 147 47 inlet; #X obj 207 47 inlet; #X obj 147 105 spigot; #X obj 147 136 t a b; #X obj 225 115 0; #X obj 207 79 1; #X obj 147 224 outlet; #X connect 0 0 2 0; #X connect 1 0 5 0; #X connect 2 0 3 0; #X connect 3 0 6 0; #X connect 3 1 4 0; #X connect 4 0 2 1; #X connect 5 0 2 1; #X restore 116 220 pd once; #X obj 153 199 b; #X connect 0 0 15 0; #X connect 0 1 10 0; #X connect 0 1 15 1; #X connect 1 0 6 0; #X connect 2 0 1 0; #X connect 3 0 8 0; #X connect 4 0 8 1; #X connect 5 0 4 0; #X connect 6 0 3 0; #X connect 8 0 7 0; #X connect 8 0 7 1; #X connect 9 0 13 1; #X connect 10 0 11 0; #X connect 10 1 12 0; #X connect 11 0 13 0; #X connect 12 0 13 0; #X connect 13 0 9 0; #X connect 13 0 14 0; #X connect 14 0 16 0; #X connect 14 0 18 0; #X connect 15 0 2 0; #X connect 15 1 17 0; #X connect 16 0 3 1; #X connect 17 0 16 0; #X connect 18 0 17 1;
Steffen Leve Poulsen wrote:
same as previous, but only trigger at the beginning of phrase.
It doesn't seem to work as I expected. Should I do something special to get it to play first note when releasing the second?
OK I havent tried your external. Can you describe it's functionality. Or send me the DLL.
mvh Steffen Leve Poulsen
Atte André Jensen skrev:
Steffen Leve Poulsen wrote:
same as previous, but only trigger at the beginning of phrase.
It doesn't seem to work as I expected. Should I do something special to get it to play first note when releasing the second?
Steffen Leve Poulsen wrote:
OK I havent tried your external. Can you describe it's functionality.
[legato] transforms output from [notein] inlet 1: note inlet 2: velocity inlet 3: mode: 0: last note hit priority (default) 1: low note priority 2: high note priority
outlet 1: note outlet 2: velocity (non re-triggered) outlet 3: velocity (re-triggered)
Notice: outlets only output values when they actually change. FOr instance if two notes are played legato, the socond note will not make outlet 2 (velocity) transmit a new value for velocity.
Example: Play (and hold) note 1, note 1 will sound. Play (and hold) note 2, note 2 will sound. Release note 2, note 1 will sound. This works for unlimited depth (actually 200) and any combination of press/release order. This description is valid for mode 0. So basically: when more than one note is pressed, the latest one pressed will sound.
Or send me the DLL.
What's a DLL?
Frank Barknecht wrote:
Hallo, Atte Andr? Jensen hat gesagt: // Atte Andr? Jensen wrote:
Or send me the DLL.
What's a DLL?
It would be called *.pd_win, if Bill Gates was Linus Thorvalds.
actually pd searches for a .m_i386 before it tries .dll
mf.asdr IOhannes
PS: having a hard time to resist pd_lose....
Ciao
Attached has the basics of mode 0. It's a very good idea you got, great fun to play with.
mvh /Steffen Leve Poulsen
Atte André Jensen skrev:
Steffen Leve Poulsen wrote:
OK I havent tried your external. Can you describe it's functionality.
[legato] transforms output from [notein] inlet 1: note inlet 2: velocity inlet 3: mode: 0: last note hit priority (default) 1: low note priority 2: high note priority
outlet 1: note outlet 2: velocity (non re-triggered) outlet 3: velocity (re-triggered)
Notice: outlets only output values when they actually change. FOr instance if two notes are played legato, the socond note will not make outlet 2 (velocity) transmit a new value for velocity.
Example: Play (and hold) note 1, note 1 will sound. Play (and hold) note 2, note 2 will sound. Release note 2, note 1 will sound. This works for unlimited depth (actually 200) and any combination of press/release order. This description is valid for mode 0. So basically: when more than one note is pressed, the latest one pressed will sound.
#N canvas 556 21 365 683 10; #X obj 60 57 notein; #X obj 60 283 phasor~; #X obj 60 254 mtof; #X obj 60 365 *~; #X obj 78 483 dbtorms; #X obj 81 459 hsl 128 15 0 100 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 9500 1; #X obj 61 311 -~ 0.5; #X obj 58 532 dac~; #X obj 105 313 adsr 1 5 500 50 500; #X obj 189 85 table memo-$0 12346; #X obj 59 507 *~ 0.1; #N canvas 257 64 437 609 legato 0; #X obj 93 28 inlet; #X obj 180 39 inlet; #X obj 221 164 f; #X obj 180 61 select 0; #X obj 175 126 - 1; #X msg 223 97 1; #X obj 191 164 +; #X obj 118 292 tabwrite memo-$0; #X obj 93 260 t b f; #X obj 93 355 tabread memo-$0; #X obj 93 334 f; #X obj 242 385 outlet; #X obj 93 385 outlet; #X obj 191 195 moses 1; #X obj 191 241 t f f f; #X obj 242 355 change; #X obj 134 247 0; #X obj 93 63 stripnote; #X obj 157 95 t b b b; #X obj 303 390 outlet; #X obj 242 326 f; #X connect 0 0 17 0; #X connect 1 0 3 0; #X connect 1 0 17 1; #X connect 2 0 6 1; #X connect 3 0 18 0; #X connect 3 1 5 0; #X connect 4 0 6 0; #X connect 5 0 6 0; #X connect 6 0 2 0; #X connect 6 0 13 0; #X connect 8 0 10 0; #X connect 8 1 7 0; #X connect 9 0 12 0; #X connect 10 0 9 0; #X connect 13 0 20 0; #X connect 13 1 14 0; #X connect 14 0 10 1; #X connect 14 1 7 1; #X connect 14 2 20 0; #X connect 15 0 11 0; #X connect 16 0 7 0; #X connect 17 0 8 0; #X connect 18 0 10 0; #X connect 18 1 4 0; #X connect 18 2 16 0; #X connect 20 0 15 0; #X connect 20 0 19 0; #X restore 60 85 pd legato mode 0; #X connect 0 0 11 0; #X connect 0 1 11 1; #X connect 1 0 6 0; #X connect 2 0 1 0; #X connect 3 0 10 0; #X connect 4 0 10 1; #X connect 5 0 4 0; #X connect 6 0 3 0; #X connect 8 0 3 1; #X connect 10 0 7 0; #X connect 10 0 7 1; #X connect 11 0 2 0; #X connect 11 1 8 0;
On Wed, Sep 12, 2007 at 08:10:42AM +0200, Atte André Jensen wrote:
Chris McCormick wrote:
In this particular case of Andre's legato object,
The name is Atte :-)
My apologies, how rude of me!
I see no positive reason whatsoever for it being an external. I see several positive reasons for it being an abstraction:
I made it because I needed it and I couldn't find a similar functionality.
The reason I made it as an external was:
- Being new to PD I simply couldn't figure out how to do it as an
abstraction. All the little logics involved made me feel like building a ship in a bottle with PD. In C (or any full blown language), it's quite easy.
- I wanted to try my hands on an external.
Excellent points, and as some others have pointed out there are other very good reasons to use Pd as the 'glue' to tie your home-brew externals together.
My comment comes from the point of view of someone who got tired of compiling long ago and wishes that everything was just Pd-patches so I could re-use, and hack away without ever having to type 'make' or 'gcc' on the command line. Basically laziness and hubris are my motivation! (And I type 'make' and 'gcc' often enough in my day job to be really really bored of it by the time I want to relax and write some music).
But I'm looking forward to seeing your implementation as an abstraction, it will help me understand PD more!
That might be a long time coming given the abundance of laziness and hubris around here. ;)
Best,
Chris.
-
Atte André Jensen -
Chris McCormick -
Frank Barknecht -
IOhannes m zmoelnig -
Phil Stone -
Roman Haefeli -
Steffen -
Steffen Leve Poulsen