Re: [PD] achieving smooth tempo change

[Roman Haefeli]

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 +, 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 

Re: [PD] achieving smooth tempo change

[Lorenzo Sutton]

Hi,

You don't provide any detail about your project/use case so it's very 
hard to try and give suggestions on such a theoretical base.


Your initial similarity with DAWs is somewhat misleading as you mention 
a global setting (that is correct most DAWs/sequencers have a general 
BPM setting). But then you state (if I understand correctly) that you 
don't want to use a global tempo/timing source in your project ("keeping 
time locally").


Independent time objects in environments like Pd are intrinsically... 
independent (I would say that's a neat feature!): you can of course find 
ways to have these objects 'communicate' with each other.


Something which might (or might not) be relevant is that you can also 
use audio-rate objects (i.e. phasor~) to do timing. For example a 
phasor~ with a frequency of 1 Hz has a period of 1 second, etc. 
(samphold~ might also be relevant??).


But as said if would really be helpful to know what you're trying to 
achieve ;)


Lorenzo.

On 11/02/2016 06:14, 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.

[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!



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



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

Re: [PD] pd-0.46-7: segfault with jack-1.9.10

[Xavier Miller]

Hi!

Test without DBUS, same results: segmentation fault.

I run jackd with those parameters:
/usr/bin/jackd -P80 -u -dalsa -dhw:0 -r48000 -p512 -n3

Kind regards,
Xavier Miller.

Le 11/02/16 21:01, IOhannes m zmölnig a écrit :

On 02/11/2016 08:58 PM, Xavier Miller wrote:

I use jack-dbus. I attached the ~/config/jack/conf.xml file


would it be possible to *not* use jack-dbus for testing?

mgfdsar
IOhannes



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


--- Begin Message ---
Hi!

Test without DBUS, same results: segmentation fault.

I run jackd with those parameters:
/usr/bin/jackd -P80 -u -dalsa -dhw:0 -r48000 -p512 -n3

Kind regards,
Xavier Miller.

Le 11/02/16 21:01, IOhannes m zmölnig a écrit :
> On 02/11/2016 08:58 PM, Xavier Miller wrote:
>> I use jack-dbus. I attached the ~/config/jack/conf.xml file
> 
> would it be possible to *not* use jack-dbus for testing?
> 
> mgfdsar
> IOhannes
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
> 
--- End Message ---
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd-0.46-7: segfault with jack-1.9.10

[IOhannes m zmölnig]

On 02/11/2016 08:58 PM, Xavier Miller wrote:
> I use jack-dbus. I attached the ~/config/jack/conf.xml file

would it be possible to *not* use jack-dbus for testing?

mgfdsar
IOhannes



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

Re: [PD] pd-0.46-7: segfault with jack-1.9.10

[Xavier Miller]

Le 11/02/16 20:48, IOhannes m zmölnig a écrit :
> On 02/11/2016 08:41 PM, Xavier Miller wrote:
>> 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.
> 
> there have been a few similar bug-reports [1228].
> 
> i just checked and on my Debian sid(amd64) system, i am running
> jack-1.9.11 without any problems.
> 
> 
> $ jackd --version
> jackdmp 1.9.11
> Copyright 2001-2005 Paul Davis and others.
> Copyright 2004-2014 Grame.
> jackdmp comes with ABSOLUTELY NO WARRANTY
> This is free software, and you are welcome to redistribute it
> under certain conditions; see the file COPYING for details
> jackdmp version 1.9.11 tmpdir /dev/shm protocol 8
> $
> 
> it's usually running as:
> 
> $ /usr/bin/jackd -dalsa -dhw:PCH -r48000 -p1024 -n2
> 
> 
> could you also post your jack configuration (e.g. the startup flags used)?

I use jack-dbus. I attached the ~/config/jack/conf.xml file

> 
Xavier




 
  alsa
  true
  80
  false
  500
 
 
  
  
  
   hw:0
   hw:0
   hw:0
   48000
   512
   3
   false
   false
   true
   false
   false
   n
   false
  
  
  
  
  
  
  
  
  
 
 
  
  
  
  
  
  
  
  
 

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

Re: [PD] pd-0.46-7: segfault with jack-1.9.10

[IOhannes m zmölnig]

On 02/11/2016 08:41 PM, Xavier Miller wrote:
> 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.

there have been a few similar bug-reports [1228].

i just checked and on my Debian sid(amd64) system, i am running
jack-1.9.11 without any problems.


$ jackd --version
jackdmp 1.9.11
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2014 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
jackdmp version 1.9.11 tmpdir /dev/shm protocol 8
$

it's usually running as:

$ /usr/bin/jackd -dalsa -dhw:PCH -r48000 -p1024 -n2


could you also post your jack configuration (e.g. the startup flags used)?



gmsdr
IOhannes


[1228] https://sf.net/p/pure-data/bugs/1228/




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

[PD] pd-0.46-7: segfault with jack-1.9.10

[Xavier Miller]

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.

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

Re: [PD] achieving smooth tempo change

[cyrille henry]

hello,

since 0.45, delay and metro accept a tempo message that is probably doing what 
you expect.

but it did not affect the line object.

cheers
c


Le 11/02/2016 06:14, Liam Goodacre a écrit :

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!



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



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

Re: [PD] Cyclone: List of Issues with existing objects by Alexandre Porres

[Alexandre Torres Porres]

guess some of it is in:
http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html

As with *nettles*

"try to resurrect as independent object library"

Anyway, tell me if this gets includes on this file.

cheers

ps. count me in for help with the help files

2016-02-11 22:18 GMT-02:00 Alexandre Torres Porres :

> 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-3nXy2Qlk8/edit?usp=sharing
>
> 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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] loading random samples

[Spyros Polychronopoulos]

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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Cyclone To Do: list of new objects; Any help?

[Alexandre Torres Porres]

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/1CBRd1sOf4ebJmdqQfUtcCJzS2ZRhvMgoyLz8pNPD6mc/edit?usp=sharing

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


Cyclone-NewObjects.pdf
Description: Adobe PDF document
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list