"I do not completely understand the Description of the Max5 cycle~: when
should I make the 513th sample the same as the 512th and when should I
use the first? The latest implementation always uses the first."

you should never make the 513th the same as the 512th. 

The idea is that it operates with a 512 size table, but internally it needs 513 points, where the 513th is for interpolation and needs to be the same as the 1st point.

So, when a user specify a 512 size table, the cycle~ documentation in Max5 says it'll create a 513 points table where the 513th point is the same as the 1st.

This happens cause it is a simple linear interpolation. In Pd we have a 4 point interpolation in objects such as tabread4, so you need the first point to be the same as the last, and also need two extra last points to be the same as the first two points (so you need 3 extra points). The sinesum command for tables will generate these extra points automatically, and tabosc4~ will read these wavetables also in the correct way.

Back to max 5 documentation and cycle~... It also says that if someone is specifying a 513 size table, that they should make sure that the 513th sample is the same as the 1st. Because in this case the object won't do anything and will just get the specified table.

So creating a copy of the 1st sample to be the 513th sample is a behaviour in cycle~ only for given tables that are 512 in size. This is what I was asking you, if it really behaved that way. What do you say?

This makes me believe that when you specify a bigger table, like 1024, and start offsetting it, that it won't do anything to make this interpolation perfect, but it'll consider the "extra" 513th point in the table to be the same as the first. This is not a real problem in the real world, you can't really perceive it...

cheers

2015-06-11 4:09 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl>:
Hi Alexandre,

> So, hey Fred, would you be able to get into sourceforge and close all
> the bug reports that have already been taken care of?
>
> I'm not sure how to get in it and do it. I guess I should do that to
> cause I'm aware of a few things that are going on, so if anyone could
> tell me how to do it, I'd like to try and collaborate.
>

IOhannes changed the policy, so any registered developer can close
issues. I already started closing some of which I was reasonable sure
they were fixed. Some others, I want to check  first.

> Moreover, still about [cycle~], I just wanted to make sure it behaves
> exactly like it says in Max 5 documentation. They descibre how it needs
> a table with 513 points, and that the 513 needs to be the same as the
> 1st because of the interpolation (I assume it does a simple linear
> interpolation then, right?). In the case of a table with 512 points,
> [cycle~] will add a 513th point that's a copy of the first. Anyway, this
> is what it says in the documentation and I'd like to check with you if
> it's working exactly like that as well. Perhaps you could mention that
> too in the help file.

Yesterday, I updated the cyclone binary distributions at
http://puredata.info/Members/fjkraan. The simplest way to install the
correct one is using the deken-plugin:
https://github.com/pure-data/deken. If you use Pd-extended, you have to
rename or remove the original cyclone directory, to prevent having two
cyclones.

Indeed, simple interpolation is used. From the cycle_perform:
*out++ = f1 + frac * (f2 - f1);

I replaced the core of the cycle_gettable, and in case of an external
array, the 513th sample is copied from the first.

I do not completely understand the Description of the Max5 cycle~: when
should I make the 513th sample the same as the 512th and when should I
use the first? The latest implementation always uses the first.

>
> cheers

Fred Jan
>
> 2015-06-09 10:46 GMT-03:00 Alexandre Torres Porres <porres@gmail.com
> <mailto:porres@gmail.com>>:
>
>     collected all bug reports related to cyclone. It'd be good to
>     commitor close/mark as fixed.
>
>     http://sourceforge.net/p/pure-data/bugs/991/
>
>     http://sourceforge.net/p/pure-data/bugs/950/
>
>     http://sourceforge.net/p/pure-data/bugs/652/
>
>     http://sourceforge.net/p/pure-data/bugs/647/
>
>     http://sourceforge.net/p/pure-data/bugs/215/
>
>     http://sourceforge.net/p/pure-data/bugs/163/
>
>     http://sourceforge.net/p/pure-data/bugs/78/
>
>     http://sourceforge.net/p/pure-data/bugs/1188/
>
>     http://sourceforge.net/p/pure-data/bugs/1186/
>
>     http://sourceforge.net/p/pure-data/bugs/1128/ (that was me actually,
>     haha)
>
>     2015-06-09 10:15 GMT-03:00 Alexandre Torres Porres <porres@gmail.com
>     <mailto:porres@gmail.com>>:
>
>         another report for [rand~], by the way, maybe you should get
>         involved here and mark them as fixed
>
>         http://sourceforge.net/p/pure-data/bugs/1177/
>
>
>
>         2015-06-09 10:12 GMT-03:00 Alexandre Torres Porres
>         <porres@gmail.com <mailto:porres@gmail.com>>:
>
>                 About the sample-offset, I have some problem
>                 understanding how it works,
>                 and have to change it anyhow to fix the issue
>                 (garray_getarraywords
>                 related on 64-bit systems).
>
>
>             seems there was a bug report about this :)
>             http://sourceforge.net/p/pure-data/bugs/1180/
>
>
>
>
>
>     _______________________________________________
>     Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
>     UNSUBSCRIBE and account-management ->
>     http://lists.puredata.info/listinfo/pd-list
>
>