Pd-list February 2016

pd-list@lists.iem.at

91 participants
131 discussions

Does Pd have a "sound"?
by Samuel Burt 15 Feb '16

15 Feb '16

If anything Pd's sound would be related to its 64 sample block size that is mostly evident when people don't use sample rate line~ objects to smooth their signals. I'd say many other audio environments provide easy tools for dynamics management, reverberation, and EQ. This creates a particular sound for those environments. The fact that you have to build these from scratch in Pd causes me to assume that the easiest to build routines for these purposes would influence the sound of neophyte patches, but as people develope more sophisticated and original processes, there would be a significant diverging of sonic characteristics between patches. One final thing that might influence the "sound" of Pd or Max is the use of whole numbers to represent frequencies and time values that are determined in milliseconds. This might make a lot of patches sound like they are based on the harmonic spectrum of 1Hz. TLDR: If you want a more sophisticated sound, use line~ objects to smooth signal rate control of audio processes, build your own dynamics management, reverberation, and filter told, and make sure to use a variety of floating point numbers or other special ratios to determine frequencies and durations. At this point, I don't think people could tell your sound came from Pd. > > > Message: 3 > Date: Mon, 15 Feb 2016 00:27:08 +0200 > From: Matti Viljamaa <mviljamaa(a)kapsi.fi> > To: Pd-List <pd-list(a)lists.iem.at> > Subject: [PD] Does Pd have a "sound"? > Message-ID: <D9A862C4-2F6E-4BFB-9D7D-B48A0DEC5A82(a)kapsi.fi> > Content-Type: text/plain; charset=utf-8 > > Do you think Pd has a characteristic sound to it? Or whether discussion > board threads claiming Pd (and Max) have a distinct (and not good) sound > just have people who haven’t listened to good patches? > > -Matti > > > > > > ------------------------------ > > Message: 4 > Date: Sun, 14 Feb 2016 23:32:18 +0100 > From: Antoine Rousseau <antoine(a)metalu.net> > To: Pd-list <pd-list(a)lists.iem.at> > Subject: Re: [PD] Nettles. Was: Cyclone: List of Issues with existing > objects by Alexandre Porres > Message-ID: > < > CAOCG5HwDcssRYAdkw9MQ1QvV-LivXDYfkVzYZaV2E1mH7znv0Q(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I've only partially followed all this discussion (not using Max myself), > but maybe an object I wrote could help you building such abstractions : > > [moonlib/dinlet~] is an [inlet~] with an init float value (constant signal) > as an argument. > This default value is overloaded when a signal is connected to the inlet, > but restored when the signal is disconnected. A float sent to it would > overwrite the default constant value. > > Of course the init default value could be one of the abstraction's > arguments ($xxx)... > > BUT : > > - there is a very little hack (which could be called a bugfix...) that has > to be made to pd source (this change is written in comment in the source > file of dinlet~). I should open a ticket for that in the sourceforge repo. > The involved bug is mixing the different float values up when [dinlet~] is > used together with normal [inlet]s. > > - I should add a missing feature in dinlet~, which would add an inlet to > the [dinlet~] object itself, to allow changing the default value inside of > the abstraction. > > If anyone think this would be helpful, I could do this (open a ticket and > update moonlib about this missing inlet). > > > > 2016-02-14 20:29 GMT+01:00 Jonathan Wilkes via Pd-list < > pd-list(a)lists.iem.at > >: > > > > Why not simply have an inlet that can handle both inside an abstraction > > and route signal one way and number the other and then sprinkle that with > > dynamic nlet creation and you're done? Then you can simply abstract most > > cases. > > > > I read (and like) your spec on dynamic nlet creation, but I have a > problem > > with section 2.1 Signals: > > > > "To handle the dynamic creation of signal inlets and their routing within > > the abstraction, the implementation must" > > > > It looks like the rest of the section is missing. :) > > > > -Jonathan > > > > > > > > > > On Sunday, February 14, 2016 1:51 PM, Matt Barber <brbrofsvl(a)gmail.com> > > wrote: > > > > > > I tried coding that once, but it seemed like it needed some big change > in > > architecture. Technically it's only the main signal that accepts both > > messages and signals in this way, where you would want to route the > > message. Floats should almost always be promoted to signals. > > > > On Sun, Feb 14, 2016 at 1:18 PM, Ivica Ico Bukvic <ico(a)vt.edu> wrote: > > > > Why not simply have an inlet that can handle both inside an abstraction > > and route signal one way and number the other and then sprinkle that with > > dynamic nlet creation and you're done? Then you can simply abstract most > > cases. > > > > > > On 2/14/2016 11:36 AM, Matt Barber wrote: > > > > [gt~] is a great example of something that could work as an abstraction, > > except for the pesky right inlet which should take a signal if there's no > > creation argument, but float otherwise. > > > > On Sun, Feb 14, 2016 at 10:50 AM, Ivica Bukvic <ico(a)vt.edu> wrote: > > > > What I am also trying to do eventually in pd-l2ork is weed out redundant > > objects and only keep the ones that do the said task the best while still > > supporting other objects' idiosyncrasies (if any). There is absolutely no > > reason to have multiple objects of the same kind. Ultimately, one could > > keep all the externals in the same folder and completely do away with all > > the declares, imports, and other things that make learning pd > unnecessarily > > harder. > > -- > > Ivica Ico Bukvic, D.M.A. > > Associate Professor > > Computer Music > > ICAT Senior Fellow > > Director -- DISIS, L2Ork > > Virginia Tech > > School of Performing Arts – 0141 > > Blacksburg, VA 24061 > > (540) 231-6139 > > ico(a)vt.edu > > www.performingarts.vt.edu > > disis.icat.vt.edu > > l2ork.icat.vt.edu > > ico.bukvic.net > > On Feb 14, 2016 8:40 AM, "Fred Jan Kraan" <fjkraan(a)xs4all.nl> wrote: > > > > Hi Alexandre, > > > > guess some of it is in: > > http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html > > > > > > This list is also becoming a list of what has been done. > > > > > > As with _nettles_ > > > > "try to resurrect as independent object library" > > > > Anyway, tell me if this gets includes on this file. > > > > > > Yes, the nettles-objects are part of the latest cyclone versions. They > are > > part of the nettles library, which can be loaded with [declare]. Not all > > operating systems like the '<' and '>' in the object names and there is > > overlap with other library objects, so only loading them when needed is > > cleaner. > > > > > > cheers > > > > ps. count me in for help with the help files > > > > > > Great! > > > > Greetings, > > > > Fred Jan > > > > > > 2016-02-11 22:18 GMT-02:00 Alexandre Torres Porres <porres(a)gmail.com > > <mailto:porres@gmail.com>>: > > > > Howdy, it's a known fact brazilians will start the year only after > > carnival, so here I am. > > > > I'd like to share my list of things to do with existing Cyclone > > Objetcs. Obviously there might be other issues with other objects > > that would make them up to date with the current version of Max (Max > > 7). Nonetheless, this is what I find relevant, and I've been really > > checking it through. > > > > It's only about 11 objects, some has already been discussed here and > > might have been fixed or in the process to be taken care of, forgive > > me if so. > > > > I have it attached and also as a link to a google doc > > > > > > > https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2… > > > > Next, I will get together a list of new objects I think should be > > included, many of which I've already made as abstractions (kind of > > to show how it works like I did with [teeth~], cause I really think > > they should all be done as externals). > > > > Cheers > > > > > > > > _______________________________________________ > > Pd-list(a)lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > <http://lists.puredata.info/listinfo/pd-list> > > http://lists.puredata.info/listinfo/pd-list > > > > > > _______________________________________________ > > Pd-list(a)lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > <http://lists.puredata.info/listinfo/pd-list> > > http://lists.puredata.info/listinfo/pd-list > > > > > > > > > > > > _______________________________________________ > > Pd-list(a)lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > > > > > _______________________________________________ > > Pd-list(a)lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > >

4 4

Re: [PD] Cleaned patch for Jupiter (Maxence Larrieu)
by Maxence Larrieu 14 Feb '16

14 Feb '16

Hello, thanks for the feedback, as usual the error come from the student (me) : the synthesis "chapo" works fine now (see section 6 and 12). now lets see the problems with spat and the samplers (interpolation). new patch is there http://jupiter.larri.eu/patch/ and readme here : http://jupiter.larri.eu/ greetings, Maxence 2016-02-08 10:44 GMT+01:00 <pd-list-request(a)lists.iem.at>: > Send Pd-list mailing list submissions to > pd-list(a)lists.iem.at > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.puredata.info/listinfo/pd-list > or, via email, send a message with subject or body 'help' to > pd-list-request(a)lists.iem.at > > You can reach the person managing the list at > pd-list-owner(a)lists.iem.at > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pd-list digest..." > > > Today's Topics: > > 1. Re: Cleaned patch for Jupiter (Miller Puckette) > 2. Re: freeverb~ problem (Kjetil Matheussen) > 3. Re: freeverb~ problem (Kjetil Matheussen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 7 Feb 2016 21:05:42 -0800 > From: Miller Puckette <msp(a)ucsd.edu> > To: Maxence Larrieu <m(a)larri.eu> > Cc: pd-list(a)lists.iem.at > Subject: Re: [PD] Cleaned patch for Jupiter > Message-ID: <20160208050542.GO23918(a)fuzz.localdomain> > Content-Type: text/plain; charset=utf-8 > > I do think the distributed patch should work. (One minor thing: "chapo" > puts out no sound until the pitch tracker gets a pitch from the input). > Anyhow, I've run many performances with it. > > I'm not sure what the table "goobers" ever did :) > > cheers > Miller > > On Fri, Feb 05, 2016 at 05:17:12PM +0100, Maxence Larrieu wrote: > > Hello, > > > > I am working on Jupiter patch which is present in the Pd Repertory > Project > > [1]. The problem is that this original patch (maybe the one which have > the > > longest history since it starts in 1987 ;) is not fully functional. For > > example one synthesis named "chapo" do not outputs signal (see [2] in pd > > forum) and few tables needed in the patch are empty ( goobers, expo.tab, > > fto4.t, dist.t). > > > > I would like to make a functionnal patch, and to make it as readeable as > > possible. > > I need help for "debugging", and understand what it should do. > > If some of you are interested let me know so we can work together. > > > > I share the last "cleaned patch" version there, with all depedencies > (lib, > > abstraction, sounds) : > > http://jupiter.larri.eu/patch/ > > > > You can find a readme file (editable) + an error list (not exhaustive) > > there : > > http://jupiter.larri.eu/index.html > > > > > > I hope some of you will be interested, > > greetings, > > Maxence Larrieu > > > > [1]http://msp.ucsd.edu/pdrp/latest/files/doc/ > > [2]http://forum.pdpatchrepo.info/topic/9781/help-synthesis > > > > <https://lite6.framapad.org/p/jupiter> > > > _______________________________________________ > > Pd-list(a)lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > ------------------------------ > > Message: 2 > Date: Mon, 8 Feb 2016 10:28:05 +0100 > From: Kjetil Matheussen <k.s.matheussen(a)gmail.com> > To: Ivica Bukvic <ico(a)vt.edu> > Cc: IOhannes m zmoelnig <zmoelnig(a)iem.at>, Pd-list > <pd-list(a)lists.iem.at> > Subject: Re: [PD] freeverb~ problem > Message-ID: > < > CAC6niELAsyOT-sRdrDiwF8r2E+5kZ1ESTTAhD5TdQQP7GFeTUw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > You could use the faust version of freeverb and compile it for pd. It's > probably less likely to have bugs. > For instance by pasting > > http://sourceforge.net/p/faudiostream/code/ci/master/tree/examples/freeverb… > into http://faust.grame.fr/onlinecompiler/ > > > On Sun, Feb 7, 2016 at 4:08 AM, Ivica Bukvic <ico(a)vt.edu> wrote: > > > Thank you, Katja. Is there a newer version than this out there? > > > > Best, > > > > -- > > Ivica Ico Bukvic, D.M.A. > > Associate Professor > > Computer Music > > ICAT Senior Fellow > > Director -- DISIS, L2Ork > > Virginia Tech > > School of Performing Arts – 0141 > > Blacksburg, VA 24061 > > (540) 231-6139 > > ico(a)vt.edu > > www.performingarts.vt.edu > > disis.icat.vt.edu > > l2ork.icat.vt.edu > > ico.bukvic.net > > On Feb 6, 2016 10:25 AM, "katja" <katjavetter(a)gmail.com> wrote: > > > >> If the freeverb~ version you use looks like the one in > >> > >> > http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/freeverb~/… > >> , > >> there's a function 'fix_denorm_nan_float() defined starting at line > >> 154. The function is called later (in line 225 and others) but the > >> return value is never stored. Therefore freeverb~ doesn't flush > >> denormals. > >> > >> On Sat, Feb 6, 2016 at 3:34 PM, Ivica Bukvic <ico(a)vt.edu> wrote: > >> > Thank you all. Looks like I've got some troubleshooting to do and will > >> > report what I find. > >> > > >> > Best, > >> > > >> > -- > >> > Ivica Ico Bukvic, D.M.A. > >> > Associate Professor > >> > Computer Music > >> > ICAT Senior Fellow > >> > Director -- DISIS, L2Ork > >> > Virginia Tech > >> > School of Performing Arts – 0141 > >> > Blacksburg, VA 24061 > >> > (540) 231-6139 > >> > ico(a)vt.edu > >> > www.performingarts.vt.edu > >> > disis.icat.vt.edu > >> > l2ork.icat.vt.edu > >> > ico.bukvic.net > >> > > >> > On Feb 6, 2016 9:20 AM, "IOhannes m zmölnig" <zmoelnig(a)iem.at> wrote: > >> >> > >> >> On 02/06/2016 10:29 AM, katja wrote: > >> >> > Possibly an inf or nan recirculating in the delay lines? It seems > >> that > >> >> > freeverb~ calls function fix_denorm_nan_float(float v) but doesn't > >> use > >> >> > the return value. > >> >> > >> >> you *might* be able to confirm this by sending the output for > >> >> [freeverb~] to [print~] (the silent samples would be NaN or Inf > rather > >> >> than 0 (or some other constant value)) > >> >> > >> >> gamds > >> >> IOhannes > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> Pd-list(a)lists.iem.at mailing list > >> >> UNSUBSCRIBE and account-management -> > >> >> http://lists.puredata.info/listinfo/pd-list > >> >> > >> > > >> > _______________________________________________ > >> > Pd-list(a)lists.iem.at mailing list > >> > UNSUBSCRIBE and account-management -> > >> > http://lists.puredata.info/listinfo/pd-list > >> > > >> > > > > _______________________________________________ > > Pd-list(a)lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > >

1 0

Cyclone To Do: list of new objects; Any help?
by Alexandre Torres Porres 14 Feb '16

14 Feb '16

Howdy, here's a list of relevant new objects to include as externals in Pd. some of them are here because they are just easy and because I was able to do as abstractions or even make an external code draft. Some aren't that simple but I've made into abstractions as well. Anyway, this is what I find important and suggest to have as externals in Pd as we're still missing useful features from them see attachment and the google docs here https://docs.google.com/document/d/1CBRd1sOf4ebJmdqQfUtcCJzS2ZRhvMgoyLz8pNP… Since I can't code, and since I realize that maintaining the existing library is enough work for now for Fred Jan, we'd need help from enthusiastic coders out there, so I'm trying to recrute friends for the task. cheers

3 4

comb~ bug (was Re: New [comb~] help file)
by Alexandre Torres Porres 13 Feb '16

13 Feb '16

> But in Pd it's actually only (D, a, b, c), Oops, no, not really, in the help file you had actually just 3 arguments in that list message (D a b), and that's quite wrong. Moreover, I was testing this message and it's just seems to not work well at all. So there's quite a bug right there. So, to fix it, we should make it a 5 list argument message and that works well. while at it, make sure if the default max delay is 10 ms when not specified (or when = 0, that would be clever too). cheers 2016-02-13 18:11 GMT-02:00 Alexandre Torres Porres <porres(a)gmail.com>: > I added another info that I saw on Max's help file about the maximum > delay. When not specified, it is set to 10 ms. > > Although I included this information, I'm not sure if that's how it works > in Pd, so this needed to be checked and corrected if not. > > Another thing is that I found that the list message with arguments in Max > does set ALL the arguments (max delay, D, a, b, c). But in Pd it's actually > only (D, a, b, c), so we're missing a way to change the maximum buffer > size, which is limiting and also a bug. > > Attached is the new help file with this information and considering the > argument list message is how it should be (max delay, D, a, b, c). > > cheers > > 2016-02-13 17:12 GMT-02:00 Alexandre Torres Porres <porres(a)gmail.com>: > >> I found problems in the help file of [comb~] so I made a new version >> correcting it and giving more information, find it attached >> >> cheers >> >> >

1 0

New [comb~] help file (was: Cyclone: List of Issues with existing objects by Alexandre Porres)
by Alexandre Torres Porres 13 Feb '16

13 Feb '16

I found problems in the help file of [comb~] so I made a new version correcting it and giving more information, find it attached cheers

1 1

configuring multiple readanysf~ objects for efficient playback
by Samuel Burt 13 Feb '16

13 Feb '16

Dear list, I was tasked with building a sampler that reads back all the samples in a directory, sequentially or randomly, with variable speed, polyphonic playback. The subsequent object is then implemented multiple times. After a short amount of time, however, the GUI becomes unresponsive. I can still manipulate the values of the GUI objects, but I won't see them update. In addition, the Pd window Log 0 and above starts throwing (Tcl) INVALID COMMAND NAME errors as you can see below. I'm guessing this is has to do with not being able to read from the SSD quickly enough with around 100 overlapping voices being loaded in a short amount of time? I'm not really hearing any audio dropouts. I noticed that readanysf~ has some arguments. I'm hoping they might make this process more efficient, but I don't understand them. Does anyone know of any better documentation for readanysf~? The arguments are 1) number of channels (mono, stereo, 3-chan, 4-chan, etc.), 2) number of "frames" in the internal buffer --I don't understand how this effects the object--, and 3) number of samples per frame in internal buffer --nor do I understand how this might affect performance. I'm going to play around with these arguments to see if it helps, but if anyone can weigh in with an explanation, I'd appreciate it. Also, if anyone has a more efficient method for doing what I'm attempting, please, let me know. Thank you, Sam

2 3

loading random samples
by Spyros Polychronopoulos 13 Feb '16

13 Feb '16

Hi list, I have a question if you could enlighten me: I would like to make a patch that loads randomly a sample from a folder (if I can make it open randomly any file begging with P01 ie. P01*.wav) and when the sample ends loads automatically another sample randomly (ie. P02*.wav). thank you in advance -- Spyros Polychronopoulos Music Composer / BSc / PhD www.spyweirdos.com

6 9

Re: [PD] achieving smooth tempo change
by Liam Goodacre 12 Feb '16

12 Feb '16

Thanks guys, I was unaware of the "tempo" setting on [metro] and [delay]. This is exactly what I was after! Thanks also for the endorsement of [vline~]--I will use this in the future. > Date: Thu, 11 Feb 2016 09:44:10 +0100 > From: Roman Haefeli <reduzent(a)gmail.com> > To: pd-list(a)lists.iem.at > Subject: Re: [PD] achieving smooth tempo change > Message-ID: <1455180250.4171.22.camel(a)nl-16900.ad.zhdk.ch> > Content-Type: text/plain; charset="utf-8" > > Hi Liam > > A thread that covers the same topic: > http://lists.puredata.info/pipermail/pd-list/2016-01/112812.html > > On Thu, 2016-02-11 at 05:14 +0000, Liam Goodacre wrote: > > Any DAW or sequencer has a global setting which allows you to change > > the tempo smoothly across all elements. But fool around on PD for a > > while and you will realize that this is not a simple operation. If you > > have more than one time object going at once, it is very hard to keep > > them in time with each other while changing the period. > > > > Consider the example of two metros set to 500 and 1000 ms, banging in > > synch with one another. The "cold" inlet of both are connected to a > > float, with the second one being multiplied by 2 along the way. I'm > > sure you don't even need to try this to know that the two metros will > > quickly faze out quite if you scroll through the value. The metro > > duration updates only after the cycle is complete, so one updates > > before the other and it quickly gets chaotic, especially if you drag > > the value for more than one complete metro cycle. Of course you could > > keep them in time by using a trigger to reset the metros, but this is > > not good from a musical perspective, because I don't want to go > > restart the bar every time I change the tempo. Another possibility is > > to store the new time value and load it only when both cycles > > coincide. This should keep both metros in time, although the > > transition wouldn't be very smooth. > > Checkout the help of [delay] (>= Pd 0.45). It illustrates a new 'tempo' > method that tackles this exact problem, i.e. using 'tempo' allows to > change time intervals in the middle of a running interval. The same > method can be used for [metro] and [timer], too. > > > > [line] works differently, in that the time is specified in the "hot" > > inlet. But this also doesn't update smoothly if you interrupt it with > > a new message before the cycle has finished, because the new value > > sent to it will take the last point as a starting point. The total > > duration of its cycle will be {elapsed time} + {new time}, which isn't > > very good if you want to change tempo smoothly. I worked on trying to > > solve this for a while, and came up with a prototype solution which I > > am attaching. It works by taking the new time and subtracting it from > > elapsed time for the new value, so that the line finishes its cycle as > > if the new time value had been given at the beginning. The patch works > > reasonably well for one iteration, but completely fails for more than > > one (ie. if you scroll through the time values). I still haven't > > figured out why. > > I think you're on the right path. If an update happens, measure the time > since the start of the ramp, calculate the current position, generate a > new ramp that starts at the current position and takes the proportional > rest of the time interval to complete. I cannot think of another way to > achieve that. > > I think this is supposed to work even when updating more than once > during one ramp. > > > Before I open up for suggestions, here are a few other points: > > > > 1. The simplest solution to this would be to have one and only one > > time object, set to say 1/16th beat or whatever is the smallest time > > interval you want, acting globally on all other sequenced events. This > > would work simply and elegantly, but unfortunately it is not an option > > for my project. Keeping time locally is essential to me, and I would > > sooner give up tempo change altogether than give this up. > > And it doesn't work well, if you want to have many different ratios of > beats in parallel. Soon your common partial interval will be so small, > that [metro] significantly hogs the CPU. If you're interested in keeping > many different timing ratios in sync, checkout master.pd and > abs/master-poly.pd from https://github.com/reduzent/netpd-instruments/ . > While [master] provides the master clock, any instance of [master-poly] > can derive any arbitrary integer ratio time interval for it (for > instance, [master-poly 9 5] would create 9 ticks withing the time of 5 > master ticks). > > > 2. Another option would be to use the [timer] object, either as an > > alternative to the others, or to help calculate feedback for them. I'm > > hesitant to do this because a: it seems like it would require more CPU > > and b: it it seems like an empirical solution to a deterministic > > problem. > > I don't know how this is a deterministic problem. You don't know when > the user decides to make a tempo change. So you're left with measuring > the time elapsed since ramp start or last interval or whatever. If you > know beforehand, when a tempo change is going to occur, then you don't > need [timer] to get elapsed time. > > > My intuition says that this > > problem can be solved mathematically, without resorting to > > measurement. However, I am willing to be convinced that this is the > > right way to go. > > > > 3. I assume that [line] and [line~] will work identically in this > > regard, > > No, [line~] does start and end ramps exactly on block boundaries, while > [vline~] is sub-sample precise. Only [vline~] takes into account the > precision of [metro] and [delay]. For the things you're working on, I > strongly suggest using [vline~], since [line~] would cause all kinds of > glitches. > > > and that [delay] and > > [metro] will work similarly. But [line] and [delay] work in very > > different ways, and so the solution, if it exists, is likely to be > > quite different for these objects. Ultimately I want to find a > > solution for all time objects, so I'm willing to hear anything you've > > got! > > Checkout the 'tempo' method of [metro], [delay], [timer]. > > Roman

1 0

pd-0.46-7: segfault with jack-1.9.10
by Xavier Miller 11 Feb '16

11 Feb '16

Hi! I am compiling pd-0.46-7 in Gento, using jack-1.9.10, but when I enable jack in the configure script, pd segfaults. It runs OK with ALSA. What information can I give to find the problem? Kind regards, Xavier Miller.

2 3

achieving smooth tempo change
by Liam Goodacre 11 Feb '16

11 Feb '16

Any DAW or sequencer has a global setting which allows you to change the tempo smoothly across all elements. But fool around on PD for a while and you will realize that this is not a simple operation. If you have more than one time object going at once, it is very hard to keep them in time with each other while changing the period. Consider the example of two metros set to 500 and 1000 ms, banging in synch with one another. The "cold" inlet of both are connected to a float, with the second one being multiplied by 2 along the way. I'm sure you don't even need to try this to know that the two metros will quickly faze out quite if you scroll through the value. The metro duration updates only after the cycle is complete, so one updates before the other and it quickly gets chaotic, especially if you drag the value for more than one complete metro cycle. Of course you could keep them in time by using a trigger to reset the metros, but this is not good from a musical perspective, because I don't want to go restart the bar every time I change the tempo. Another possibility is to store the new time value and load it only when both cycles coincide. This should keep both metros in time, although the transition wouldn't be very smooth. [line] works differently, in that the time is specified in the "hot" inlet. But this also doesn't update smoothly if you interrupt it with a new message before the cycle has finished, because the new value sent to it will take the last point as a starting point. The total duration of its cycle will be {elapsed time} + {new time}, which isn't very good if you want to change tempo smoothly. I worked on trying to solve this for a while, and came up with a prototype solution which I am attaching. It works by taking the new time and subtracting it from elapsed time for the new value, so that the line finishes its cycle as if the new time value had been given at the beginning. The patch works reasonably well for one iteration, but completely fails for more than one (ie. if you scroll through the time values). I still haven't figured out why. Before I open up for suggestions, here are a few other points: 1. The simplest solution to this would be to have one and only one time object, set to say 1/16th beat or whatever is the smallest time interval you want, acting globally on all other sequenced events. This would work simply and elegantly, but unfortunately it is not an option for my project. Keeping time locally is essential to me, and I would sooner give up tempo change altogether than give this up. 2. Another option would be to use the [timer] object, either as an alternative to the others, or to help calculate feedback for them. I'm hesitant to do this because a: it seems like it would require more CPU and b: it it seems like an empirical solution to a deterministic problem. My intuition says that this problem can be solved mathematically, without resorting to measurement. However, I am willing to be convinced that this is the right way to go. 3. I assume that [line] and [line~] will work identically in this regard, and that [delay] and [metro] will work similarly. But [line] and [delay] work in very different ways, and so the solution, if it exists, is likely to be quite different for these objects. Ultimately I want to find a solution for all time objects, so I'm willing to hear anything you've got!

4 3

← Newer
1
...
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list February 2016