Hello list,
I'm having trouble using partconv~ in a freshly compiled pd-0.46.6 on Ubuntu 14.04.
First, if I use the distro-supplied pd-bsaylor package, then I get the usual 64bit error message: "An operation on the array '1003-ns_coeffs' in the patch '1003-ns_coeffs' failed since it uses garray_getfloatarray while running 64-bit!"
I then compiled bsaylor from svn (partconv~.c from 2013/01/02, where 64bit access is supposedly fixed) and voila - no error message, pd apparently loads partconv~ ok: "partconv~: using 1003-ns_coeffs in 1 partitions with FFT-size 1024"
Unfortunately, I don't get anything out of the filter. The fiter itself works (e.g. using FIR~).
Any hints? Thanks, Matthias
On 07/17/2015 11:30 AM, Matthias Blau wrote:
Hello list,
I'm having trouble using partconv~ in a freshly compiled pd-0.46.6 on Ubuntu 14.04.
First, if I use the distro-supplied pd-bsaylor package, then I get the usual 64bit error message:
if this a usual error message for you and it is fixed in svn, then it seems you have forgotten to report a bug (with Ubuntu/Debian/...): $ reportbug pd-bsaylor
you are encouraged to do that for all buggy packages provided by your system. else they won't ever get fixed (esp. since most pd-* packages are not really active upstream - "active" as in "doing releases").
mgdsr IOhannes
Hi Matthias,
Using the same configuration (xubuntu 14.04 / pd-0.46-6), I have no trouble getting sound from the partconv~-help.pd patch, although I had to make a correction to fill both arrays: "[read -resize $1 irL irR(" to soundfiler didn't seem to load irR. And without something to convolve with, the result is silence.
Greetings,
Fred Jan
On 2015-07-17 11:30 AM, Matthias Blau wrote:
Hello list,
I'm having trouble using partconv~ in a freshly compiled pd-0.46.6 on Ubuntu 14.04.
First, if I use the distro-supplied pd-bsaylor package, then I get the usual 64bit error message: "An operation on the array '1003-ns_coeffs' in the patch '1003-ns_coeffs' failed since it uses garray_getfloatarray while running 64-bit!"
I then compiled bsaylor from svn (partconv~.c from 2013/01/02, where 64bit access is supposedly fixed) and voila - no error message, pd apparently loads partconv~ ok: "partconv~: using 1003-ns_coeffs in 1 partitions with FFT-size 1024"
Unfortunately, I don't get anything out of the filter. The fiter itself works (e.g. using FIR~).
Any hints? Thanks, Matthias
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
partconv~ needs to receive a set message to set the table, otherwise it wont work with the specified array given as the first argument and it will crash. So it needs a loadbang to set the table. I contacted the author (bensaylor), who said this is a known bug but that he didn't have time to work on it.
I tried to make a bug report on on it just now, but sourceforge seems to be down - i got http://sourceforge.net/error-404.html
anyway, I see many objects and libraries have been kind of abandoned and I worry and wonder about the odds of someone else jumping in and maintaining them :/
cheers
2015-07-17 8:49 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi Matthias,
Using the same configuration (xubuntu 14.04 / pd-0.46-6), I have no trouble getting sound from the partconv~-help.pd patch, although I had to make a correction to fill both arrays: "[read -resize $1 irL irR(" to soundfiler didn't seem to load irR. And without something to convolve with, the result is silence.
Greetings,
Fred Jan
On 2015-07-17 11:30 AM, Matthias Blau wrote:
Hello list,
I'm having trouble using partconv~ in a freshly compiled pd-0.46.6 on Ubuntu 14.04.
First, if I use the distro-supplied pd-bsaylor package, then I get the usual 64bit error message: "An operation on the array '1003-ns_coeffs' in the patch '1003-ns_coeffs' failed since it uses garray_getfloatarray while running 64-bit!"
I then compiled bsaylor from svn (partconv~.c from 2013/01/02, where 64bit access is supposedly fixed) and voila - no error message, pd apparently loads partconv~ ok: "partconv~: using 1003-ns_coeffs in 1 partitions with FFT-size 1024"
Unfortunately, I don't get anything out of the filter. The fiter itself works (e.g. using FIR~).
Any hints? Thanks, Matthias
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
Hi All,
On 2015-07-17 06:56 PM, Alexandre Torres Porres wrote:
partconv~ needs to receive a set message to set the table, otherwise it wont work with the specified array given as the first argument and it will crash. So it needs a loadbang to set the table. I contacted the author (bensaylor), who said this is a known bug but that he didn't have time to work on it.
Some time ago I ran into probably the same issue; how to load an array/table at load time, while said array/table is not guaranteed to have loaded yet. From within an object there is nothing like a loadbang AFAIK. I ended up setting a timer for one second (clock_new()) and load the array/timer when it finishes. But the good news is that just preventing partconv~ to crash shouldn't be too difficult.
I tried to make a bug report on on it just now, but sourceforge seems to be down - i got http://sourceforge.net/error-404.html
anyway, I see many objects and libraries have been kind of abandoned and I worry and wonder about the odds of someone else jumping in and maintaining them :/
Still it is a good idea to make detailed bug reports. Fixing issues is much simpler if you know exactly what the problem is.
cheers
Greetings,
Fred Jan
2015-07-17 8:49 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl>:
Hi Matthias, Using the same configuration (xubuntu 14.04 / pd-0.46-6), I have no trouble getting sound from the partconv~-help.pd patch, although I had to make a correction to fill both arrays: "[read -resize $1 irL irR(" to soundfiler didn't seem to load irR. And without something to convolve with, the result is silence. Greetings, Fred Jan On 2015-07-17 11:30 AM, Matthias Blau wrote: > Hello list, > > I'm having trouble using partconv~ in a freshly compiled pd-0.46.6 on > Ubuntu 14.04. > > First, if I use the distro-supplied pd-bsaylor package, then I get the > usual 64bit error message: > "An operation on the array '1003-ns_coeffs' in the patch > '1003-ns_coeffs' failed since it uses garray_getfloatarray while running > 64-bit!" > > I then compiled bsaylor from svn (partconv~.c from 2013/01/02, where > 64bit access is supposedly fixed) and voila - no error message, pd > apparently loads partconv~ ok: > "partconv~: using 1003-ns_coeffs in 1 partitions with FFT-size 1024" > > Unfortunately, I don't get anything out of the filter. The fiter itself > works (e.g. using FIR~). > > Any hints? > Thanks, Matthias > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto: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
On 07/19/2015 10:52 AM, Fred Jan Kraan wrote:
Some time ago I ran into probably the same issue; how to load an array/table at load time, while said array/table is not guaranteed to have loaded yet. From within an object there is nothing like a loadbang AFAIK. I ended up setting a timer for one second (clock_new()) and load the array/timer when it finishes.
hmm, i wouldn't recommend that. having an external initialize itself after some arbitrary time is prone to hard-to-find errors. most likely the user doesn't know that something special is happening after 1000ms. they also might schedule their own initialization to happen "long enough after startup" (e.g. 1000ms), which will then somehow conflict.
if you cannot use the table "as is" (and in [partconv~] you cannot), i think the object should use an (internal) loadbang for initialization. if the table is not ready at that time, the user should do a proper initialization on the patch side (after all, they are the only ones who can know when all required initialisation has taken place - and they can only know if the object don't break the process by doing it "somewhat later".
But the good news is that just preventing partconv~ to crash shouldn't be too difficult.
cool, and should be fixed.
gfmdsar IOhannes
On 2015-07-19 07:46 PM, IOhannes m zmölnig wrote:
On 07/19/2015 10:52 AM, Fred Jan Kraan wrote:
Some time ago I ran into probably the same issue; how to load an array/table at load time, while said array/table is not guaranteed to have loaded yet. From within an object there is nothing like a loadbang AFAIK. I ended up setting a timer for one second (clock_new()) and load the array/timer when it finishes.
hmm, i wouldn't recommend that. having an external initialize itself after some arbitrary time is prone to hard-to-find errors. most likely the user doesn't know that something special is happening after 1000ms. they also might schedule their own initialization to happen "long enough after startup" (e.g. 1000ms), which will then somehow conflict.
I consider it a hack, not a proper solution. I mentioned it hoping to get some clue on how to fix it properly here ;-).
if you cannot use the table "as is" (and in [partconv~] you cannot), i think the object should use an (internal) loadbang for initialization. if the table is not ready at that time, the user should do a proper initialization on the patch side (after all, they are the only ones who can know when all required initialisation has taken place - and they can only know if the object don't break the process by doing it "somewhat later".
"internal loadbang" sounds about right. I will try to find out how [loadbang] does its magic. If it cannot be made to work, the table name probably shouldn't be an argument to partconv~.
But the good news is that just preventing partconv~ to crash shouldn't be too difficult.
cool, and should be fixed.
There is already a patch ready for this that seems to work and doesn't look too ugly.
gfmdsar IOhannes
Greetings,
Fred Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hi, what is so hard about initializing the object with a table? The [cycle~] object does that really well, for example.
And I don't see how it wouldn't work if the table had its contents saved, for example...
attached there's a patch using cycle, the table is initialized in the patch with a loadbang, and it still works - remembering that whenever changes are made in the table, cycle needs to be reset so it loads the table back.
cheers
2015-07-19 15:40 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
On 2015-07-19 07:46 PM, IOhannes m zmölnig wrote:
On 07/19/2015 10:52 AM, Fred Jan Kraan wrote:
Some time ago I ran into probably the same issue; how to load an array/table at load time, while said array/table is not guaranteed to have loaded yet. From within an object there is nothing like a loadbang AFAIK. I ended up setting a timer for one second (clock_new()) and load the array/timer when it finishes.
hmm, i wouldn't recommend that. having an external initialize itself after some arbitrary time is prone to hard-to-find errors. most likely the user doesn't know that something special is happening after 1000ms. they also might schedule their own initialization to happen "long enough after startup" (e.g. 1000ms), which will then somehow conflict.
I consider it a hack, not a proper solution. I mentioned it hoping to get some clue on how to fix it properly here ;-).
if you cannot use the table "as is" (and in [partconv~] you cannot), i think the object should use an (internal) loadbang for initialization. if the table is not ready at that time, the user should do a proper initialization on the patch side (after all, they are the only ones who can know when all required initialisation has taken place - and they can only know if the object don't break the process by doing it "somewhat later".
"internal loadbang" sounds about right. I will try to find out how [loadbang] does its magic. If it cannot be made to work, the table name probably shouldn't be an argument to partconv~.
But the good news is that just preventing partconv~ to crash shouldn't be too difficult.
cool, and should be fixed.
There is already a patch ready for this that seems to work and doesn't look too ugly.
gfmdsar IOhannes
Greetings,
Fred Jan
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
bugs can't be reported yet
SourceForge developer pages are presently offline. See our Twitter feed for more information.
2015-07-19 15:46 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
hi, what is so hard about initializing the object with a table? The [cycle~] object does that really well, for example.
And I don't see how it wouldn't work if the table had its contents saved, for example...
attached there's a patch using cycle, the table is initialized in the patch with a loadbang, and it still works - remembering that whenever changes are made in the table, cycle needs to be reset so it loads the table back.
cheers
2015-07-19 15:40 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
On 2015-07-19 07:46 PM, IOhannes m zmölnig wrote:
On 07/19/2015 10:52 AM, Fred Jan Kraan wrote:
Some time ago I ran into probably the same issue; how to load an array/table at load time, while said array/table is not guaranteed to have loaded yet. From within an object there is nothing like a loadbang AFAIK. I ended up setting a timer for one second (clock_new()) and load the array/timer when it finishes.
hmm, i wouldn't recommend that. having an external initialize itself after some arbitrary time is prone to hard-to-find errors. most likely the user doesn't know that something special is happening after 1000ms. they also might schedule their own initialization to happen "long enough after startup" (e.g. 1000ms), which will then somehow conflict.
I consider it a hack, not a proper solution. I mentioned it hoping to get some clue on how to fix it properly here ;-).
if you cannot use the table "as is" (and in [partconv~] you cannot), i think the object should use an (internal) loadbang for initialization. if the table is not ready at that time, the user should do a proper initialization on the patch side (after all, they are the only ones who can know when all required initialisation has taken place - and they can only know if the object don't break the process by doing it "somewhat later".
"internal loadbang" sounds about right. I will try to find out how [loadbang] does its magic. If it cannot be made to work, the table name probably shouldn't be an argument to partconv~.
But the good news is that just preventing partconv~ to crash shouldn't be too difficult.
cool, and should be fixed.
There is already a patch ready for this that seems to work and doesn't look too ugly.
gfmdsar IOhannes
Greetings,
Fred Jan
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
On 07/19/2015 08:46 PM, Alexandre Torres Porres wrote:
hi, what is so hard about initializing the object with a table? The [cycle~] object does that really well, for example.
it's very simple if the object can access the table-values directly when needed. e.g. [tabread] (we don't need to search for max-compat externals to have a use-case...) will check whether a table exists directly before it accesses it; [tabosc~] (that's [cycle~], ain't it?) and other dsp-objects will check whether the table exists when DSP is turned on (Pd guarantees that whenever a table appears or disappears the DSP is re-started).
but some externals (including [partconv~]) are slightly different, as they don't access the table-values directly. rather they munge the data in the table into a local representation (in the case of [partconv~] the data will be fft-transformed), which is rather time-consuming.
i *guess* that even for [partconv~] it would be enough to not access the table-data before the DSP is started. this might need major refactoring though.
And I don't see how it wouldn't work if the table had its contents saved, for example...
have the [partconv~] object be created before the [table]?
gfmrdsa IOhannes
On 07/19/2015 09:55 PM, IOhannes m zmölnig wrote:
And I don't see how it wouldn't work if the table had its contents saved, for example...
have the [partconv~] object be created before the [table]?
in any case: a table saving its own content is an edge case. if your [partconv~] only works with tables that have in-patch-data, i would consider it broken (=> more broken than it currently is).
... storing table data within patches doesn't scale well: among other things it uses the second most inefficient storage format and doesn't allow to use different data in multiple instances...
fmsdr IOhannes
On 2015-07-19 09:55 PM, IOhannes m zmölnig wrote:
i *guess* that even for [partconv~] it would be enough to not access the table-data before the DSP is started. this might need major refactoring though.
[partconv~] does access the table at DSP start, but somehow this doesn't work properly. I'll look into it.
gfmrdsa IOhannes
Greetings,
Fred Jan
- Fred Jan Kraan fjkraan@xs4all.nl [2015-07-19 16:55]:
On 2015-07-19 09:55 PM, IOhannes m zmölnig wrote:
i *guess* that even for [partconv~] it would be enough to not access the table-data before the DSP is started. this might need major refactoring though.
[partconv~] does access the table at DSP start, but somehow this doesn't work properly. I'll look into it.
Hi Fred, I am chiming in here beacause I discovered that partconv~ plays its convolution kernel (table) once out of its output when DSP is turned on.
And I discovered a similar related a few weeks ago (and reported them to the original author). IOhannes, do you want me to file this as debian package bug?
I found that the object plays a part of its convolution kernel out of its outlet when switching tables using a "set ..." message with another table name. At least this happens in my case. I somehow was able to measure the length of this unintentional playback. In my case I have a Pd table of 2048 samples length, partconv~ with 2048 as partition size, and when I ask the object to (re)read the audio data from the table, it plays a loud burping noise of approx. 4096 samples length.
It would of course be fantastic to be able to switch between tables without this.
best, Peter
On 2015-07-20 00:04, Peter P. wrote:
And I discovered a similar related a few weeks ago (and reported them to the original author). IOhannes, do you want me to file this as debian package bug?
yes. all users of Debian packages, please always file a bug against the Debian package if you encounter strangenesses.
the main problem is really, that there are virtually no releases from the svn (apart from a few select projects); which makes it rather hard to track all casual fixes of bugs.
fgmasdr IOhannes
On 2015-07-20 10:17 AM, IOhannes m zmoelnig wrote:
the main problem is really, that there are virtually no releases from the svn (apart from a few select projects); which makes it rather hard to track all casual fixes of bugs.
Isn't the Debian repository downstream of svn? I always assumed this.
fgmasdr IOhannes
Greetings,
Fred Jan
On 2015-07-20 11:21, Fred Jan Kraan wrote:
On 2015-07-20 10:17 AM, IOhannes m zmoelnig wrote:
the main problem is really, that there are virtually no releases from the svn (apart from a few select projects); which makes it rather hard to track all casual fixes of bugs.
Isn't the Debian repository downstream of svn? I always assumed this.
yes it's downstream.
but it doesn't automatically use the newest version found in svn. that would be a nightmare considering reproducibility and stability (don't think Pd-extended play-a-gig-tonight scale; think Debian/Ubuntu/Mint/SteamOS/... server grade scale). therefore, a human being (aka Debian maintainer) needs to manually import new upstream sources whenever they feel the urge to. this is done most easily if upstream does regular (or irregular) releases. unfortunately most externals in our sf repository don't do releases at all. which puts a lot of additional work on the Debian maintainers. enough load, so that bug-fixes that are merely pushed to the svn most of the time will not make it to Debian and friends unless the Debian people are called to attention. the way to call them to attention is by reporting bugs in the Debian bugtracker.
until recently¹, all Pd-related packages had zero (0) bugs files in both the Debian and the Ubuntu bug tracker.
reporting bugs downstream usually has the advantage that the bugs will get forwarded to upstream by the maintainer - often with an accompanying patch that fixes the problem...
fgmdsdr IOhannes
¹ last friday (17.07.2015) i filed 9 bugs due to incorrect use of array_getfloatarray (found automatically; so some of them *might* be false-positives)
- IOhannes m zmoelnig zmoelnig@iem.at [2015-07-20 04:17]:
On 2015-07-20 00:04, Peter P. wrote:
And I discovered a similar related a few weeks ago (and reported them to the original author). IOhannes, do you want me to file this as debian package bug?
yes. all users of Debian packages, please always file a bug against the Debian package if you encounter strangenesses.
I reckon that users of compiles-from-svn then still write to the original authors, or is there another way of reporting bugs apart from debian-package-maintainer-reporting?
Thanks again! P
On 07/21/2015 07:11 PM, Peter P. wrote:
- IOhannes m zmoelnig zmoelnig@iem.at [2015-07-20 04:17]:
all users of Debian packages, please always file a bug against the Debian package if you encounter strangenesses.
I reckon that users of compiles-from-svn then still write to the original authors, or is there another way of reporting bugs apart from debian-package-maintainer-reporting?
not sure i totally understand.
in general, you should report bugs to the *closest* upstream you got the package from. if you got the package via Debian, report to Debian. if you got the package from Santa Clause, report to Santa Clause. if you got the package from the author (e.g. an svn clone), report to the author.
a downstream (Debian, Santa,...) should then report the problem to *their closest* upstream, if appropriate (!, keep in mind that there might be bugs in the Debian package that were never in upstream; e.g. because Debian uses some special build flags per default; or because Fedora ships a slightly modified version of the package in order to fix another bug...)
if you are not using the Debian package, you also don't need to report bugs with Debian. apart from the chance that the bug doesn't exist in Debian at all, it is likely that you simply don't know all the various downstreams (Debian, Fedora, Gentoo, Arch, Santa, Pd-extended, pd-iem, ...) from a package.
gfmdsar IOhannes
- IOhannes m zmölnig zmoelnig@iem.at [2015-07-21 14:41]:
On 07/21/2015 07:11 PM, Peter P. wrote:
- IOhannes m zmoelnig zmoelnig@iem.at [2015-07-20 04:17]:
all users of Debian packages, please always file a bug against the Debian package if you encounter strangenesses.
I reckon that users of compiles-from-svn then still write to the original authors, or is there another way of reporting bugs apart from debian-package-maintainer-reporting?
not sure i totally understand.
in general, you should report bugs to the *closest* upstream you got the package from. if you got the package via Debian, report to Debian. if you got the package from Santa Clause, report to Santa Clause. if you got the package from the author (e.g. an svn clone), report to the author.
a downstream (Debian, Santa,...) should then report the problem to *their closest* upstream, if appropriate (!, keep in mind that there might be bugs in the Debian package that were never in upstream; e.g. because Debian uses some special build flags per default; or because Fedora ships a slightly modified version of the package in order to fix another bug...)
if you are not using the Debian package, you also don't need to report bugs with Debian. apart from the chance that the bug doesn't exist in Debian at all, it is likely that you simply don't know all the various downstreams (Debian, Fedora, Gentoo, Arch, Santa, Pd-extended, pd-iem, ...) from a package.
All understood, thanks for being so clear and helpful! best, P
have the [partconv~] object be created before the [table]?
I tried and have it working actually, not sure how it wouldn't work like I said
2015-07-19 16:55 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 07/19/2015 08:46 PM, Alexandre Torres Porres wrote:
hi, what is so hard about initializing the object with a table? The [cycle~] object does that really well, for example.
it's very simple if the object can access the table-values directly when needed. e.g. [tabread] (we don't need to search for max-compat externals to have a use-case...) will check whether a table exists directly before it accesses it; [tabosc~] (that's [cycle~], ain't it?) and other dsp-objects will check whether the table exists when DSP is turned on (Pd guarantees that whenever a table appears or disappears the DSP is re-started).
but some externals (including [partconv~]) are slightly different, as they don't access the table-values directly. rather they munge the data in the table into a local representation (in the case of [partconv~] the data will be fft-transformed), which is rather time-consuming.
i *guess* that even for [partconv~] it would be enough to not access the table-data before the DSP is started. this might need major refactoring though.
And I don't see how it wouldn't work if the table had its contents saved, for example...
have the [partconv~] object be created before the [table]?
gfmrdsa IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello all, Fred Jan,
thank you all for your help - Alexandre's remark below solved my problem.
After having sorted this out, I also noticed that even the pd-bsaylor package from Ubuntu 14.04 appears to work (regarding partconv~) although it says it encountered a 64bit error!
Best wishes, Matthias
Am 17.07.2015 um 18:56 schrieb Alexandre Torres Porres:
partconv~ needs to receive a set message to set the table, otherwise it wont work with the specified array given as the first argument and it will crash. So it needs a loadbang to set the table. I contacted the author (bensaylor), who said this is a known bug but that he didn't have time to work on it.
I tried to make a bug report on on it just now, but sourceforge seems to be down - i got http://sourceforge.net/error-404.html
anyway, I see many objects and libraries have been kind of abandoned and I worry and wonder about the odds of someone else jumping in and maintaining them :/
cheers
2015-07-17 8:49 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl>:
Hi Matthias, Using the same configuration (xubuntu 14.04 / pd-0.46-6), I have no trouble getting sound from the partconv~-help.pd patch, although I had to make a correction to fill both arrays: "[read -resize $1 irL irR(" to soundfiler didn't seem to load irR. And without something to convolve with, the result is silence. Greetings, Fred Jan On 2015-07-17 11:30 AM, Matthias Blau wrote: > Hello list, > > I'm having trouble using partconv~ in a freshly compiled pd-0.46.6 on > Ubuntu 14.04. > > First, if I use the distro-supplied pd-bsaylor package, then I get the > usual 64bit error message: > "An operation on the array '1003-ns_coeffs' in the patch > '1003-ns_coeffs' failed since it uses garray_getfloatarray while running > 64-bit!" > > I then compiled bsaylor from svn (partconv~.c from 2013/01/02, where > 64bit access is supposedly fixed) and voila - no error message, pd > apparently loads partconv~ ok: > "partconv~: using 1003-ns_coeffs in 1 partitions with FFT-size 1024" > > Unfortunately, I don't get anything out of the filter. The fiter itself > works (e.g. using FIR~). > > Any hints? > Thanks, Matthias > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto: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
Hi Matthias,
Hello all, Fred Jan,
thank you all for your help - Alexandre's remark below solved my problem.
Well, your problem might be solved by a workaround, but there are still issues with [partconv~].
After having sorted this out, I also noticed that even the pd-bsaylor package from Ubuntu 14.04 appears to work (regarding partconv~) although it says it encountered a 64bit error!
If you get the 64-bit error the values you get from the array are incorrect (at least half of them). The nice thing is, it doesn't crash. The code was updated in 2013-01-02, but the latest pd-extended may be before that.
Best wishes, Matthias
Greetings,
Fred Jan
Am 17.07.2015 um 18:56 schrieb Alexandre Torres Porres:
partconv~ needs to receive a set message to set the table, otherwise it wont work with the specified array given as the first argument and it will crash. So it needs a loadbang to set the table. I contacted the author (bensaylor), who said this is a known bug but that he didn't have time to work on it.
I tried to make a bug report on on it just now, but sourceforge seems to be down - i got http://sourceforge.net/error-404.html
anyway, I see many objects and libraries have been kind of abandoned and I worry and wonder about the odds of someone else jumping in and maintaining them :/
cheers
2015-07-17 8:49 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl>:
Hi Matthias, Using the same configuration (xubuntu 14.04 / pd-0.46-6), I have no trouble getting sound from the partconv~-help.pd patch, although I had to make a correction to fill both arrays: "[read -resize $1 irL irR(" to soundfiler didn't seem to load irR. And without something to convolve with, the result is silence. Greetings, Fred Jan On 2015-07-17 11:30 AM, Matthias Blau wrote: > Hello list, > > I'm having trouble using partconv~ in a freshly compiled pd-0.46.6 on > Ubuntu 14.04. > > First, if I use the distro-supplied pd-bsaylor package, then I get the > usual 64bit error message: > "An operation on the array '1003-ns_coeffs' in the patch > '1003-ns_coeffs' failed since it uses garray_getfloatarray while running > 64-bit!" > > I then compiled bsaylor from svn (partconv~.c from 2013/01/02, where > 64bit access is supposedly fixed) and voila - no error message, pd > apparently loads partconv~ ok: > "partconv~: using 1003-ns_coeffs in 1 partitions with FFT-size 1024" > > Unfortunately, I don't get anything out of the filter. The fiter itself > works (e.g. using FIR~). > > Any hints? > Thanks, Matthias > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto: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
On 07/19/2015 10:49 PM, Fred Jan Kraan wrote:
If you get the 64-bit error the values you get from the array are incorrect (at least half of them). The nice thing is, it doesn't crash. The code was updated in 2013-01-02, but the latest pd-extended may be before that.
iiuc, matthias refers to the standard Debian (and ubuntu) package "pd-bsaylor". i have created a number of bug-reports last night regarding this issue with Debian packages. i guess i will be able to fix them next week.
i cannot stress enough, that we are depending on the feedback of users to *report* any issues, rather than hoping that they will be magically fixed.
gfmsard IOhannes
-
Alexandre Torres Porres -
Fred Jan Kraan -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Matthias Blau -
Peter P.