Has anybody figured out the problem with [delwrite~] and [delread~] with the -nogui flag?
I'm not getting it to work. And on top of it both my reverbs (freeverb~ + fdn~) are not working either anymore. Everything is fine with the gui turned on.
I have delayed turning dsp on by 10 seconds already. It doesn't help. I had to make an abstraction also to replace [susloop~] which gave up on me also with -nogui.
Everything was working fine up until Ubuntu 7.10. With 8.04 and later I started to have problems so I stayed with 7.10 for the -nogui stuff. Now I need to get it going with the current OS.
If anybody has found a solution please help me!
Ingo
same here in debian 64 virtual server...i do not know what to
do.....but maybe since we are two of us now, the list might be more
merciful in helping...
I tried to switch~ off the delays at loading and switch them on after
50ms...no effect....i tried the hint doing starting with -nodac, no
sucsess...
these are the posts i did in the last 10 days without any
response....and i stuck...and it schould work
both of us good luck der.brandt
hello again
I mentioned following problem in a virtual 64 bit debian system:
if I cast the stream from my windoze laptop, all of the delays are
working properly, if i
do the same on the virtual system, non of them are working anymore
i still do not have any glue and didn´t find anything in the list archive...
even if i just run the example patch G01.delay.pd adding the oggcast~
enviroment, I just
can hear the original signal. If i run it from my windows machine at
home, it works
perfect. first i thought it has somthing to do with the amount of
memory on the virtual
machine, but since we ingresed the amount of ram to 138 megs, this
should not be an issue.
I mentioned following problem in a virtual 64 bit debian system:
if I cast the stream from my windoze laptop, all of the delays are
working pronerly, if i
do the same on the virtual system, non of them are working anymore
I tried also -noaudio without sucsess
Zitat von "Ingo Scherzinger" ingo@miamiwave.com:
Has anybody figured out the problem with [delwrite~] and [delread~] with the -nogui flag?
I'm not getting it to work. And on top of it both my reverbs (freeverb~ + fdn~) are not working either anymore. Everything is fine with the gui turned on.
I have delayed turning dsp on by 10 seconds already. It doesn't help. I had to make an abstraction also to replace [susloop~] which gave up on me also with -nogui.
Everything was working fine up until Ubuntu 7.10. With 8.04 and later I started to have problems so I stayed with 7.10 for the -nogui stuff. Now I need to get it going with the current OS.
If anybody has found a solution please help me!
Ingo
hi ingo
what i found out now is mentioned in the issue in the bugtracker
http://sourceforge.net/tracker/?func=detail&aid=2978457&group_id=557...
no workaround in the moment.
its a pity, cause a project of mine is really waiting to go on air
us both, all the best for millers fixing that bug soon
der.brandt
Zitat von "Ingo Scherzinger" ingo@miamiwave.com:
Has anybody figured out the problem with [delwrite~] and [delread~] with the -nogui flag?
I'm not getting it to work. And on top of it both my reverbs (freeverb~ + fdn~) are not working either anymore. Everything is fine with the gui turned on.
I have delayed turning dsp on by 10 seconds already. It doesn't help. I had to make an abstraction also to replace [susloop~] which gave up on me also with -nogui.
Everything was working fine up until Ubuntu 7.10. With 8.04 and later I started to have problems so I stayed with 7.10 for the -nogui stuff. Now I need to get it going with the current OS.
If anybody has found a solution please help me!
Ingo
Looks like not too many people seem to care too much about this. This bug has been around for quite a while. I suppose it's breaking all of the reverbs as well since they are working with stacked delays. I'm wondering if there is anything around to replace [delwrite~] and [delread~] that's currently not broken. Does anybody know of a reverb that works with "-nogui"? I remember there have been some others like [jonverb~] (?) and an abstraction that would replace [freeverb~]. I hope I'll find these. I might have even downloaded them(?). However, I somehow doubt that they will work.
Ingo
hi ingo
what i found out now is mentioned in the issue in the bugtracker
http://sourceforge.net/tracker/?func=detail&aid=2978457&group_id=557... 47
8070 no workaround in the moment. its a pity, cause a project of mine is really waiting to go on air us both, all the best for millers fixing that bug soon
der.brandt
Zitat von "Ingo Scherzinger" ingo@miamiwave.com:
Has anybody figured out the problem with [delwrite~] and [delread~] with
the
-nogui flag?
I'm not getting it to work. And on top of it both my reverbs (freeverb~
fdn~) are not working either anymore. Everything is fine with the gui
turned
on.
I have delayed turning dsp on by 10 seconds already. It doesn't help. I
had
to make an abstraction also to replace [susloop~] which gave up on me
also
with -nogui.
Everything was working fine up until Ubuntu 7.10. With 8.04 and later I started to have problems so I stayed with 7.10 for the -nogui stuff. Now
I
need to get it going with the current OS.
If anybody has found a solution please help me!
Ingo
On Sun, 2010-05-16 at 18:13 +0200, Ingo Scherzinger wrote:
Looks like not too many people seem to care too much about this.
Let me just say, that I do care as well. Also I couldn't find any workable workaround for this problem. There is something wrong with initialization in -nogui mode it seems, but my understanding of the Pd guts is too limited to tell anything more specific about it.
Roman
On Sun, 2010-05-16 at 18:25 +0200, Roman Haefeli wrote:
On Sun, 2010-05-16 at 18:13 +0200, Ingo Scherzinger wrote:
Looks like not too many people seem to care too much about this.
Let me just say, that I do care as well. Also I couldn't find any workable workaround for this problem. There is something wrong with initialization in -nogui mode it seems, but my understanding of the Pd guts is too limited to tell anything more specific about it.
What I meant to say is, that it seems we have to wait until with the power of understanding the problem more deeply investigates it.
Roman
On Sun, 16 May 2010, Roman Haefeli wrote:
On Sun, 2010-05-16 at 18:25 +0200, Roman Haefeli wrote:
On Sun, 2010-05-16 at 18:13 +0200, Ingo Scherzinger wrote:
Looks like not too many people seem to care too much about this.
Let me just say, that I do care as well. Also I couldn't find any workable workaround for this problem. There is something wrong with initialization in -nogui mode it seems, but my understanding of the Pd guts is too limited to tell anything more specific about it.
What I meant to say is, that it seems we have to wait until with the power of understanding the problem more deeply investigates it.
a workaround is to load the patch using
[loadbang] | [delay] | «open my-patch.pd .» | [s pd]
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Sun, 16 May 2010, Mathieu Bouchard wrote:
On Sun, 16 May 2010, Roman Haefeli wrote:
On Sun, 2010-05-16 at 18:25 +0200, Roman Haefeli wrote:
On Sun, 2010-05-16 at 18:13 +0200, Ingo Scherzinger wrote:
Looks like not too many people seem to care too much about this.
Let me just say, that I do care as well. Also I couldn't find any workable workaround for this problem. There is something wrong with initialization in -nogui mode it seems, but my understanding of the Pd guts is too limited to tell anything more specific about it.
What I meant to say is, that it seems we have to wait until with the power of understanding the problem more deeply investigates it.
more generally, [delwrite~] fails to handle any change of sampling rate, and sampling rate is 0 while a patch loads, unless you load it with [delay].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Thanks to all of you and thank you mathieu for the workaround
yous sincerely der.brandt
Zitat von "Mathieu Bouchard" matju@artengine.ca:
On Sun, 16 May 2010, Mathieu Bouchard wrote:
On Sun, 16 May 2010, Roman Haefeli wrote:
On Sun, 2010-05-16 at 18:25 +0200, Roman Haefeli wrote:
On Sun, 2010-05-16 at 18:13 +0200, Ingo Scherzinger wrote:
Looks like not too many people seem to care too much about this.
Let me just say, that I do care as well. Also I couldn't find any workable workaround for this problem. There is something wrong with initialization in -nogui mode it seems, but my understanding of the Pd guts is too limited to tell anything more specific about it.
What I meant to say is, that it seems we have to wait until with the power of understanding the problem more deeply investigates it.
more generally, [delwrite~] fails to handle any change of sampling
rate, and sampling rate is 0 while a patch loads, unless you load it
with [delay]._ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Sun, 16 May 2010, brandt@subnet.at wrote:
Thanks to all of you and thank you mathieu for the workaround
you actually don't need this workaround, because here's the fix :
--- d_delay.c (révision 13558) +++ d_delay.c (copie de travail) @@ -24,6 +24,7 @@ { t_object x_obj; t_symbol *x_sym;
@@ -34,6 +35,21 @@ #define XTRASAMPS 4 #define SAMPBLK 4
+static void sigdelwrite_updatesr (t_sigdelwrite *x, t_float sr) +{
x->x_cspace.c_vec = (t_sample *)resizebytes(x->x_cspace.c_vec,
(x->x_cspace.c_n + XTRASAMPS) * sizeof(t_sample),
( nsamps + XTRASAMPS) * sizeof(t_sample));
x->x_cspace.c_n = nsamps;
x->x_cspace.c_phase = XTRASAMPS;
+}
/* routine to check that all delwrites/delreads/vds have same vecsize */
static void sigdelwrite_checkvecsize(t_sigdelwrite *x, int vecsize)
{@@ -54,19 +70,13 @@
static void *sigdelwrite_new(t_symbol *s, t_floatarg msec) {
(t_sample *)getbytes((nsamps + XTRASAMPS) * sizeof(t_sample));
@@ -109,6 +119,7 @@ dsp_add(sigdelwrite_perform, 3, sp[0]->s_vec, &x->x_cspace, sp[0]->s_n); x->x_sortno = ugen_getsortno(); sigdelwrite_checkvecsize(x, sp[0]->s_n);
sigdelwrite_updatesr(x, sp[0]->s_sr); }
static void sigdelwrite_free(t_sigdelwrite *x)
@@ -180,6 +191,7 @@ int delsamps = *(int *)(w[3]); int n = (int)(w[4]); int phase = c->c_phase - delsamps, nsamps = c->c_n;
t_sample *vp = c->c_vec, *bp, *ep = vp + (c->c_n + XTRASAMPS);
if (phase < 0) phase += nsamps;
bp = vp + phase;
@@ -197,6 +209,7 @@ t_sigdelwrite *delwriter = (t_sigdelwrite *)pd_findbyclass(x->x_sym, sigdelwrite_class); x->x_sr = sp[0]->s_sr * 0.001;
@@ -206,8 +219,7 @@ sigdelread_float(x, x->x_deltime); dsp_add(sigdelread_perform, 4, sp[0]->s_vec, &delwriter->x_cspace, &x->x_delsamps, sp[0]->s_n);
} else if (*x->x_sym->s_name) error("delread~: %s: no such delwrite~",x->x_sym->s_name); }
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Hi
Thank you again, but what to do with it.....my problem is that i am
still "just" a patcher. i didn´t jet even find out how to compile on a
windows machine. .....sigh
der.brandt
Zitat von "Mathieu Bouchard" matju@artengine.ca:
On Sun, 16 May 2010, brandt@subnet.at wrote:
Thanks to all of you and thank you mathieu for the workaround
you actually don't need this workaround, because here's the fix :
--- d_delay.c (révision 13558) +++ d_delay.c (copie de travail) @@ -24,6 +24,7 @@ { t_object x_obj; t_symbol *x_sym;
- t_float x_deltime; /* delay in msec */ t_delwritectl x_cspace; int x_sortno; /* DSP sort number at which this was last put
on chain */ int x_rsortno; /* DSP sort # for first delread or write in chain */ @@ -34,6 +35,21 @@ #define XTRASAMPS 4 #define SAMPBLK 4
+static void sigdelwrite_updatesr (t_sigdelwrite *x, t_float sr) +{
- int nsamps = x->x_deltime * sr * (t_float)(0.001f);
- if (nsamps < 1) nsamps = 1;
- nsamps += ((- nsamps) & (SAMPBLK - 1));
- nsamps += DEFDELVS;
- if (x->x_cspace.c_n != nsamps) {
x->x_cspace.c_vec = (t_sample *)resizebytes(x->x_cspace.c_vec,
(x->x_cspace.c_n + XTRASAMPS) * sizeof(t_sample),
( nsamps + XTRASAMPS) * sizeof(t_sample));
x->x_cspace.c_n = nsamps;
x->x_cspace.c_phase = XTRASAMPS;
- }
+}
- /* routine to check that all delwrites/delreads/vds have same vecsize */
static void sigdelwrite_checkvecsize(t_sigdelwrite *x, int vecsize) { @@ -54,19 +70,13 @@
static void *sigdelwrite_new(t_symbol *s, t_floatarg msec) {
- int nsamps; t_sigdelwrite *x = (t_sigdelwrite *)pd_new(sigdelwrite_class); if (!*s->s_name) s = gensym("delwrite~"); pd_bind(&x->x_obj.ob_pd, s); x->x_sym = s;
- nsamps = msec * sys_getsr() * (t_float)(0.001f);
- if (nsamps < 1) nsamps = 1;
- nsamps += ((- nsamps) & (SAMPBLK - 1));
- nsamps += DEFDELVS;
- x->x_cspace.c_n = nsamps;
- x->x_cspace.c_vec =
(t_sample *)getbytes((nsamps + XTRASAMPS) * sizeof(t_sample));
- x->x_cspace.c_phase = XTRASAMPS;
- x->x_deltime = msec;
- x->x_cspace.c_n = 0;
- x->x_cspace.c_vec = getbytes(XTRASAMPS * sizeof(t_sample)); x->x_sortno = 0; x->x_vecsize = 0; x->x_f = 0;
@@ -109,6 +119,7 @@ dsp_add(sigdelwrite_perform, 3, sp[0]->s_vec, &x->x_cspace, sp[0]->s_n); x->x_sortno = ugen_getsortno(); sigdelwrite_checkvecsize(x, sp[0]->s_n);
- sigdelwrite_updatesr(x, sp[0]->s_sr);
}
static void sigdelwrite_free(t_sigdelwrite *x) @@ -180,6 +191,7 @@ int delsamps = *(int *)(w[3]); int n = (int)(w[4]); int phase = c->c_phase - delsamps, nsamps = c->c_n;
- t_sample *vp = c->c_vec, *bp, *ep = vp + (c->c_n + XTRASAMPS); if (phase < 0) phase += nsamps; bp = vp + phase;
@@ -197,6 +209,7 @@ t_sigdelwrite *delwriter = (t_sigdelwrite *)pd_findbyclass(x->x_sym, sigdelwrite_class); x->x_sr = sp[0]->s_sr * 0.001;
- sigdelwrite_updatesr(delwriter, sp[0]->s_sr); x->x_n = sp[0]->s_n; if (delwriter) {
@@ -206,8 +219,7 @@ sigdelread_float(x, x->x_deltime); dsp_add(sigdelread_perform, 4, sp[0]->s_vec, &delwriter->x_cspace, &x->x_delsamps, sp[0]->s_n);
- }
- else if (*x->x_sym->s_name)
- } else if (*x->x_sym->s_name) error("delread~: %s: no such delwrite~",x->x_sym->s_name);
}
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
You could simply start the patch with a delay which is what I did for a quick solution! Ingo
Hi
Thank you again, but what to do with it.....my problem is that i am still "just" a patcher. i didn´t jet even find out how to compile on a windows machine. .....sigh
der.brandt
Zitat von "Mathieu Bouchard" matju@artengine.ca:
On Sun, 16 May 2010, brandt@subnet.at wrote:
Thanks to all of you and thank you mathieu for the workaround
you actually don't need this workaround, because here's the fix :
--- d_delay.c (révision 13558) +++ d_delay.c (copie de travail) @@ -24,6 +24,7 @@ { t_object x_obj; t_symbol *x_sym;
- t_float x_deltime; /* delay in msec */ t_delwritectl x_cspace; int x_sortno; /* DSP sort number at which this was last put
on chain */ int x_rsortno; /* DSP sort # for first delread or write in chain
*/
@@ -34,6 +35,21 @@ #define XTRASAMPS 4 #define SAMPBLK 4
+static void sigdelwrite_updatesr (t_sigdelwrite *x, t_float sr) +{
- int nsamps = x->x_deltime * sr * (t_float)(0.001f);
- if (nsamps < 1) nsamps = 1;
- nsamps += ((- nsamps) & (SAMPBLK - 1));
- nsamps += DEFDELVS;
- if (x->x_cspace.c_n != nsamps) {
x->x_cspace.c_vec = (t_sample *)resizebytes(x->x_cspace.c_vec,
(x->x_cspace.c_n + XTRASAMPS) * sizeof(t_sample),
( nsamps + XTRASAMPS) * sizeof(t_sample));
x->x_cspace.c_n = nsamps;
x->x_cspace.c_phase = XTRASAMPS;
- }
+}
- /* routine to check that all delwrites/delreads/vds have same
vecsize */
static void sigdelwrite_checkvecsize(t_sigdelwrite *x, int vecsize) { @@ -54,19 +70,13 @@
static void *sigdelwrite_new(t_symbol *s, t_floatarg msec) {
- int nsamps; t_sigdelwrite *x = (t_sigdelwrite *)pd_new(sigdelwrite_class); if (!*s->s_name) s = gensym("delwrite~"); pd_bind(&x->x_obj.ob_pd, s); x->x_sym = s;
- nsamps = msec * sys_getsr() * (t_float)(0.001f);
- if (nsamps < 1) nsamps = 1;
- nsamps += ((- nsamps) & (SAMPBLK - 1));
- nsamps += DEFDELVS;
- x->x_cspace.c_n = nsamps;
- x->x_cspace.c_vec =
(t_sample *)getbytes((nsamps + XTRASAMPS) * sizeof(t_sample));
- x->x_cspace.c_phase = XTRASAMPS;
- x->x_deltime = msec;
- x->x_cspace.c_n = 0;
- x->x_cspace.c_vec = getbytes(XTRASAMPS * sizeof(t_sample)); x->x_sortno = 0; x->x_vecsize = 0; x->x_f = 0;
@@ -109,6 +119,7 @@ dsp_add(sigdelwrite_perform, 3, sp[0]->s_vec, &x->x_cspace,
sp[0]->s_n);
x->x_sortno = ugen_getsortno(); sigdelwrite_checkvecsize(x, sp[0]->s_n);
- sigdelwrite_updatesr(x, sp[0]->s_sr);
}
static void sigdelwrite_free(t_sigdelwrite *x) @@ -180,6 +191,7 @@ int delsamps = *(int *)(w[3]); int n = (int)(w[4]); int phase = c->c_phase - delsamps, nsamps = c->c_n;
- t_sample *vp = c->c_vec, *bp, *ep = vp + (c->c_n + XTRASAMPS); if (phase < 0) phase += nsamps; bp = vp + phase;
@@ -197,6 +209,7 @@ t_sigdelwrite *delwriter = (t_sigdelwrite *)pd_findbyclass(x->x_sym, sigdelwrite_class); x->x_sr = sp[0]->s_sr * 0.001;
- sigdelwrite_updatesr(delwriter, sp[0]->s_sr); x->x_n = sp[0]->s_n; if (delwriter) {
@@ -206,8 +219,7 @@ sigdelread_float(x, x->x_deltime); dsp_add(sigdelread_perform, 4, sp[0]->s_vec, &delwriter->x_cspace, &x->x_delsamps,
sp[0]->s_n);
- }
- else if (*x->x_sym->s_name)
- } else if (*x->x_sym->s_name) error("delread~: %s: no such delwrite~",x->x_sym->s_name);
}
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Sun, 16 May 2010, Mathieu Bouchard wrote:
you actually don't need this workaround, because here's the fix :
ERRATUM : then move sigdelwrite_updatesr(delwriter, sp[0]->s_sr); inside if (delwriter) or else you will get crashes due to null-pointer error.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On May 17, 2010, at 4:01 PM, Mathieu Bouchard wrote:
On Sun, 16 May 2010, Mathieu Bouchard wrote:
you actually don't need this workaround, because here's the fix :
ERRATUM : then move sigdelwrite_updatesr(delwriter, sp[0]->s_sr);
inside if (delwriter) or else you will get crashes due to null- pointer error.
Hey Matju,
Thanks for the patch, could you make an updated version of this patch
and submit it to the tracker? Also, it would be helpful if the patch
did not include formatting changes like moving brackets, spacing,
etc. Then I'll check it out for inclusion in Pd-extended once I am
off this train.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Tue, 18 May 2010, Hans-Christoph Steiner wrote:
Thanks for the patch, could you make an updated version of this patch and submit it to the tracker?
No...
Also, it would be helpful if the patch did not include formatting changes like moving brackets,
I didn't move a brace nor a bracket.
Then I'll check it out for inclusion in Pd-extended once I am off this train.
You don't need a g__damn patch tracker for that.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On May 20, 2010, at 7:59 PM, Mathieu Bouchard wrote:
On Tue, 18 May 2010, Hans-Christoph Steiner wrote:
Thanks for the patch, could you make an updated version of this
patch and submit it to the tracker?No...
Also, it would be helpful if the patch did not include formatting
changes like moving brackets,I didn't move a brace nor a bracket.
Then I'll check it out for inclusion in Pd-extended once I am off
this train.You don't need a g__damn patch tracker for that.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Did I say something to anger you? I'm confused.
.hc
Mistrust authority - promote decentralization. - the hacker ethic
On Wed, 2 Jun 2010, Hans-Christoph Steiner wrote:
Did I say something to anger you? I'm confused.
commit the fix in pd-extended 0.42 and pd-devel 0.43 now and it will be done !
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Jun 4, 2010, at 1:12 PM, Mathieu Bouchard wrote:
On Wed, 2 Jun 2010, Hans-Christoph Steiner wrote:
Did I say something to anger you? I'm confused.
commit the fix in pd-extended 0.42 and pd-devel 0.43 now and it will
be done !
In my experience, when people take the trouble to submit things to the
patch tracker, they are better tested, cleaner and easier to follow.
I have had very mixed results from patches that are not submitted to
the tracker. Plus the patch tracker is how patches get into Miller's
code. I can't take on any more maintenance load of code in Pd-extended
that is not in Vanilla. Therefore, the patch tracker is quite a
useful tool here. Many projects use them, etc.
.hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
On Fri, 4 Jun 2010, Hans-Christoph Steiner wrote:
In my experience, when people take the trouble to submit things to the patch tracker, they are better tested, cleaner and easier to follow.
And if they don't take the trouble of submitting things to the patch tracker, what happens ? you just let the bug sit there ?
Plus the patch tracker is how patches get into Miller's code.
In the end, it looks like the patch tracker is the real source code management system of pure-data whereas SVN/GIT are largely irrelevant.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Jun 4, 2010, at 2:50 PM, Mathieu Bouchard wrote:
On Fri, 4 Jun 2010, Hans-Christoph Steiner wrote:
In my experience, when people take the trouble to submit things to
the patch tracker, they are better tested, cleaner and easier to
follow.And if they don't take the trouble of submitting things to the patch
tracker, what happens ? you just let the bug sit there ?
Patches can also introduce bugs. A known bug with workarounds in
better than unknown bugs, IMHO.
Plus the patch tracker is how patches get into Miller's code.
In the end, it looks like the patch tracker is the real source code
management system of pure-data whereas SVN/GIT are largely irrelevant.
The patch tracker is a tool for tracking bits of code. It has a
useful forum interface for discussions on the topic, and allows people
to see what's pending, what's accepted, rejected, etc. SVN/GIT does
not do those things.
.hc
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
On Fri, 4 Jun 2010, Hans-Christoph Steiner wrote:
On Jun 4, 2010, at 2:50 PM, Mathieu Bouchard wrote:
Patches can also introduce bugs.
Right. Such as the first version of my fix. I could have submitted that to the patch tracker as well. I don't think that you should rely on submission to the patch tracker as a sign of quality at all, even if there's somewhat a correlation. If you want quality, you ought to find it by other means.
The patch tracker is a tool for tracking bits of code. It has a useful forum interface for discussions on the topic, and allows people to see what's pending, what's accepted, rejected, etc. SVN/GIT does not do those things.
Exactly. And then if I think about what would be different if the SVN was replaced by a FTP, I'm led to believe that it wouldn't make much of a difference : pure-data is not really "using" SVN.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
It's nice to see the Pd community can agree upon such basic conventions.
On Jun 4, 2010, at 9:07 PM, Mathieu Bouchard wrote:
On Fri, 4 Jun 2010, Hans-Christoph Steiner wrote:
On Jun 4, 2010, at 2:50 PM, Mathieu Bouchard wrote:
Patches can also introduce bugs.
Right. Such as the first version of my fix. I could have submitted that to the patch tracker as well. I don't think that you should rely on submission to the patch tracker as a sign of quality at all, even if there's somewhat a correlation. If you want quality, you ought to find it by other means.
The patch tracker is a tool for tracking bits of code. It has a useful forum interface for discussions on the topic, and allows people to see what's pending, what's accepted, rejected, etc. SVN/GIT does not do those things.
Exactly. And then if I think about what would be different if the SVN was replaced by a FTP, I'm led to believe that it wouldn't make much of a difference : pure-data is not really "using" SVN.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Dan Wilcox danomatika.com robotcowboy.com
On Sat, 5 Jun 2010, Dan Wilcox wrote:
It's nice to see the Pd community can agree upon such basic conventions.
what are you trying to say ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Jun 5, 2010, at 5:16 PM, Mathieu Bouchard wrote:
On Sat, 5 Jun 2010, Dan Wilcox wrote:
It's nice to see the Pd community can agree upon such basic conventions.
what are you trying to say ?
Nothing personal ... just that I'm annoyed that these are even issues. Also endless discussions over help formats seem like such trivialities in the grand scheme of things. Other open source projects have solved these problems and moved on, will this ever happen for Pd?
Well, whatever. I always seem to start pointless arguments myself.
Dan Wilcox danomatika.com robotcowboy.com
On Sat, 5 Jun 2010, Dan Wilcox wrote:
Nothing personal ... just that I'm annoyed that these are even issues.
Then what can you say to help us ?
Also endless discussions over help formats seem like such trivialities in the grand scheme of things.
Then tell, what do you suggest that we do ?
Other open source projects have solved these problems and moved on,
Other open source projects don't have that problem with the help because their help is not written in the language itself and doesn't have that live-demo aspect to it.
will this ever happen for Pd?
You see, the advantage of open-source projects is that you can get involved if you are not happy with them. It's not guaranteed to give results all of the time, but you can make a difference over time.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Jun 5, 2010, at 6:54 PM, Mathieu Bouchard wrote:
On Sat, 5 Jun 2010, Dan Wilcox wrote:
Nothing personal ... just that I'm annoyed that these are even issues.
Then what can you say to help us ?
Use the tracker. That's what it's there for. Keeping changes to core functionality only in SVN logs works for projects with a small group of contributors who are mainly developers. Non technical users and users like myself who don't have svn commit access already submit to the tracker and as Hans said the discussion area is useful. It's nice to have an organized location for handling these issues and I'm sure it helps to lower information overload for Hans et al.
Also endless discussions over help formats seem like such trivialities in the grand scheme of things.
Then tell, what do you suggest that we do ?
Use help patches directly. We should choose the best among the existing formats and use it. Surveys from non-technical users and voting may be required. I think the input from a few workshops is far more useful then developers squabbling over which canvases and layout look best.
From what I've seen, the GEM and Gridflow helps are the best. They are very informative and professional.
Of course this would require updating the pd tutorial and externals helps. So be it. We script in a new layout template into each patch then can split up the patches up amongst ourselves to cleanup or have a sprint like the FLOSS manuals sprint.
Also, the pd gui rewrite offers possibilities such as a menu option to automatically create an svn diff of the current patch.
Other open source projects have solved these problems and moved on,
Other open source projects don't have that problem with the help because their help is not written in the language itself and doesn't have that live-demo aspect to it.
That live demo aspect is what I think makes it so intuitive. As you suggest, the basic format is obvious versus XML, html, etc. Personally I don't think a pdpedia of objects would ever be as useful or maintainable as pd help-patches.
will this ever happen for Pd?
You see, the advantage of open-source projects is that you can get involved if you are not happy with them. It's not guaranteed to give results all of the time, but you can make a difference over time.
You don't have to tell me this. I'm here, I submit bug reports and patches when I can.
Dan Wilcox danomatika.com robotcowboy.com
On Sat, 5 Jun 2010, Dan Wilcox wrote:
Use the tracker. That's what it's there for.
Alright.
Keeping changes to core functionality only in SVN logs works for projects with a small group of contributors who are mainly developers.
When it comes to the pd/src folder, Pd is a project with a small group of contributors and they are all developers.
Non technical users and users like myself who don't have svn commit access already submit to the tracker
I deleted my svn commit access on the grounds that it's not useful to have it. The SVN is used for people working alone. Each folder typically has a single committer to it. That moots much of the reason for using SVN at all.
and as Hans said the discussion area is useful.
yes. In my own projects, the discussion area is a plain MailMan mailing-list sometimes and IRC chat for the rest.
Also endless discussions over help formats seem like such trivialities in the grand scheme of things.
Then tell, what do you suggest that we do ?
Use help patches directly.
How directly ?!... I don't understand at all.
We should choose the best among the existing formats and use it.
Yeah yeah, but how do you do that ?... who is we, and what's the decision process, what happens with the people who still don't agree, etc? Those are routinely-avoided questions...
Surveys from non-technical users
technical users are also users.
the perspective of those writing the help files should count at least as much as those who only read them. After all, for help files to be read, they need to be written first. (Because of the number of writers, this means that each writer ought to count more than each reader).
and voting may be required.
You know, if there was a vote against the GridFlow format, I would not switch to a different help file format. The only format my helpfiles will migrate to, are ulterior versions of the same format.
I think the input from a few workshops is far more useful then developers squabbling over which canvases and layout look best.
The automated layout system of GridFlow was designed as such in reaction to people squabbling over which canvases and layout look best.
If you know those meetings, you know that it wasn't just a developers' meeting.
We script in a new layout template into each patch
How do you do that ?
Also, the pd gui rewrite offers possibilities such as a menu option to automatically create an svn diff of the current patch.
where's that feature ? I don't see it anywhere in the menus.
That live demo aspect is what I think makes it so intuitive. As you suggest, the basic format is obvious versus XML, html, etc.
If it were so obvious to everybody, then there would not have been a need for another thread about it (on the pdmtl mailing-list) in reaction to news of a (then upcoming) pdpedia meeting. the thread(s) was short and one-sided : it seems hard to get proponents of pdpedia to answer any questions in public...
You don't have to tell me this.
And you don't have to say things like « will this ever happen for Pd? ».
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
I like the fact that you're not afraid to ask these questions and don't gloss over the details. I have actually been spending some weeks at work looking into these kinds of issues in how we as a creative community (at work) share information and collaborate.
On Jun 5, 2010, at 9:29 PM, Mathieu Bouchard wrote:
On Sat, 5 Jun 2010, Dan Wilcox wrote:
Also endless discussions over help formats seem like such trivialities in the grand scheme of things.
Then tell, what do you suggest that we do ?
Use help patches directly.
How directly ?!... I don't understand at all.
I just meant help files in pd patche format as opposed to XML, html, etc.
We should choose the best among the existing formats and use it.
Yeah yeah, but how do you do that ?... who is we, and what's the decision process, what happens with the people who still don't agree, etc? Those are routinely-avoided questions...
Routinely avoided, exactly!
Who helps makes the decisions and arbitrates things? By we, I mean Miller, Iohannes, Hans, you, externals authors, and anyone else who wants to join. Naturally, it falls to those most active and interested. I for one want to see Pd continue to evolve and be relevant as I plan to use it professionally for years to come.
What's the decision process? I'd say the problem should be identified as well as possible requirements, a time frame give for it's resolution (important!), proposals for solutions made, the pros and cons of each listed, and a solution formulated from the strengths and weaknesses of the best proposals.
Here's my try for this case: problem: the help system is not consistent or effective in how information is formatted and displayed possible requirements: help files as patches (more intuitive) each object's arguments, inlets, and outlets should be clearly explained meta information should be encoded to allow a keyword searching system to index help patches each library should contain the author's contact information time frame for a resolution: 3 months
It's important that we all agree on the problem and the time frame for it's solution. We should try not to find the most optimal solution, but prefer a pragmatic approach and choose the best available.
What happens when people don't agree? Well, I suppose we can't do much more then try our best to compromise ... this being an open source, volunteer community. Unless we agree upon a single arbiter or "grand dictator" etc as some other projects have done, we have to *listen* to each other and be prepared to work together toward a possible solution. (Forgive me for "preaching to the choir".) I am very positive we can all agree upon reasonable compromises and *move forward* through well thought out proposals, explaining our ideas in an objective manner.
My whole point for complaining that "we quibble about the details" is that I feel we could achieve quite alot of constructive growth if we can decide upon and implement core elements such as help patches.
Surveys from non-technical users
technical users are also users.
the perspective of those writing the help files should count at least as much as those who only read them. After all, for help files to be read, they need to be written first. (Because of the number of writers, this means that each writer ought to count more than each reader).
Fair enough. My point was more that the writers should not forget who their intended audience is and should choose ease of writing over readability. The easiest solution from a writer standpoint could be that readers should refer to help in the source header files, but of course that's not practical ...
and voting may be required.
You know, if there was a vote against the GridFlow format, I would not switch to a different help file format. The only format my helpfiles will migrate to, are ulterior versions of the same format.
You are right. Voting is not a good solution. However, neither is the position of "my format or the highway". However, I suppose it was a mistake to say that we should all have a graphical template to follow and to change all existing help files to it. If I was in your position, I wouldn't want to migrate without a good reason. After all, we all patch differently, we use PD because we love the freedom in how we can work.
One possible solution would be that we can at least agree upon what help patches should contain (argument lists, inlet/outlet descriptions etc) and not bother with exact format of "this text goes here, this canvas header is this big and this color, etc". I think that would be a good improvement on the many help patches that contain the object, a slider, and a single sentence saying what it does. Then the orphan help patches are improved from there and externals authors update.
I know this is what you guys were already discussing and work has already been done, but I'm using this issue as an example for how we collaborate.
I think the input from a few workshops is far more useful then developers squabbling over which canvases and layout look best.
The automated layout system of GridFlow was designed as such in reaction to people squabbling over which canvases and layout look best.
If you know those meetings, you know that it wasn't just a developers' meeting.
I hope it wasn't a meeting like :
I remember making the point at PdCon07 that the help browser was confusing to use and I couldn't find the information I wanted (help, references) without going through each folder. A number of people gave me a dismissive look and I don't remember the responses I was given, but they were more along the lines of "it's all there, can't you see?". I got the feeling that since it wasn't a problem for those that had learned the locations of the objects and their names, then it wasn't a problem worth solving. That it was my fault and I should just read more. This did not and still does not sit well with me.
Also, the pd gui rewrite offers possibilities such as a menu option to automatically create an svn diff of the current patch.
where's that feature ? I don't see it anywhere in the menus.
As far as I know, the pd gui rewrite adds the ability for custom tcl/tk snippets through the command menu. This could be just a tcl call to svn diff.
That live demo aspect is what I think makes it so intuitive. As you suggest, the basic format is obvious versus XML, html, etc.
If it were so obvious to everybody, then there would not have been a need for another thread about it (on the pdmtl mailing-list) in reaction to news of a (then upcoming) pdpedia meeting. the thread(s) was short and one-sided : it seems hard to get proponents of pdpedia to answer any questions in public...
Good point. If discussions are not public, we are not obligated to both share and defend our ideas or viewpoints. In doing so, one has to really give thought into what one is doing. To me, it's the difference between to stating an idea then coding it directly and stating an idea, researching it, presenting it others, getting feedback, and then coding it. If we don't collaborate effectively, I feel we waste effort individually.
Also, we as a community look less active which, for an open source stand point, is not good.
You don't have to tell me this.
And you don't have to say things like « will this ever happen for Pd? ».
Fair enough. Forgive me, but I still felt it needed to be answered.
Dan Wilcox danomatika.com robotcowboy.com
Le samedi 05 juin 2010 à 23:02 +0200, Dan Wilcox a écrit :
Here's my try for this case: * problem: the help system is not consistent or effective in how information is formatted and displayed * possible requirements: * help files as patches (more intuitive) * each object's arguments, inlets, and outlets should be clearly explained * meta information should be encoded to allow a keyword searching system to index help patches * each library should contain the author's contact information * time frame for a resolution: 3 months
I agree. In possible requirements, i will add :
in a web page (like Pd Flossmanual). Therefore the help (on the web) should be always up to date.
I have developped a PHP script for this problem (I can share this script with the GEM rectangle object). It only needs a very simple pure Pd abstraction. I have to revise the layout. We need to work together (with motivated people) to define this help because there are other good ideas. ++
Jack
What does your abstraction do?
-Jonathan
From: Jack jack@rybn.org To: Dan Wilcox danomatika@gmail.com Cc: brandt@subnet.at; Ingo Scherzinger ingo@miamiwave.com; Roman Haefeli reduzierer@yahoo.de; pd-list pd-list@iem.at Sent: Sun, June 6, 2010 12:24:00 PM Subject: Re: [PD] Patch Tracker WAS no reverb or delwrite~, delread~ working with -nogui onUbuntu 10.04
Le samedi 05 juin 2010 à 23:02 +0200, Dan Wilcox a écrit :
Here's my try for this case: * problem: the help system is not consistent or effective in how information is formatted and displayed * possible requirements: * help files as patches (more intuitive) * each object's arguments, inlets, and outlets should be clearly explained * meta information should be encoded to allow a keyword searching system to index help patches * each library should contain the author's contact information * time frame for a resolution: 3 months
I agree. In possible requirements, i will add :
in a web page (like Pd Flossmanual). Therefore the help (on the web) should be always up to date.
I have developped a PHP script for this problem (I can share this script with the GEM rectangle object). It only needs a very simple pure Pd abstraction. I have to revise the layout. We need to work together (with motivated people) to define this help because there are other good ideas. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The purpose of this abstraction is to separate the example patch from the comments. Here the .zip with example. Put the directory 'fichiersPdetPHP' somewhere on an Apache server for example (with PHP) -> open 'index.php' with your web browser. Only the GEM section works (with GB and FR). As you can see there is an other help section for 'rectangle-FR-help.pd' starting by 'pourvoir' (in blue). This part is in the sub-patch [pd pourvoir] in [pd gemwin]. It is just to see if the help also work inside subpatch. ++
Jack
Le dimanche 06 juin 2010 à 09:59 -0700, Jonathan Wilkes a écrit :
What does your abstraction do?
-Jonathan
From: Jack jack@rybn.org To: Dan Wilcox danomatika@gmail.com Cc: brandt@subnet.at; Ingo Scherzinger ingo@miamiwave.com; Roman Haefeli reduzierer@yahoo.de; pd-list pd-list@iem.at Sent: Sun, June 6, 2010 12:24:00 PM Subject: Re: [PD] Patch Tracker WAS no reverb or delwrite~, delread~ working with -nogui onUbuntu 10.04
Le samedi 05 juin 2010 à 23:02 +0200, Dan Wilcox a écrit :
Here's my try for this case: * problem: the help system is not consistent or effective in
how
information is formatted and displayed * possible requirements: * help files as patches (more intuitive) * each object's arguments, inlets, and outlets should
be
clearly explained * meta information should be encoded to allow a keyword searching system to index help patches * each library should contain the author's contact information * time frame for a resolution: 3 months
I agree. In possible requirements, i will add :
- help file (as patches) should be accessible by a web site to embed
it in a web page (like Pd Flossmanual). Therefore the help (on the web) should be always up to date.
I have developped a PHP script for this problem (I can share this script with the GEM rectangle object). It only needs a very simple pure Pd abstraction. I have to revise the layout. We need to work together (with motivated people) to define this help because there are other good ideas. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sat, 5 Jun 2010, Dan Wilcox wrote:
Fair enough. My point was more that the writers should not forget who their intended audience is and should choose ease of writing over readability. The easiest solution from a writer standpoint could be that readers should refer to help in the source header files, but of course that's not practical ...
Sorry for the delay. I wrote most of the following a week ago but didn't finish the last few paragraphs... that's a long mail.
From a developer's standpoint, reading the source is not the same as
documentation, because the source doesn't tell you what it's supposed to be doing, instead it tells you what it does.
I'm not sure what you mean about the headers... pd classes don't need to be declared with .h files, so most libraries don't have any.
There was some talk about picking up runtime info from classes, such that a documentation edition system could tell you things like : canvas is missing documentation for method "bounds" and it has four f-arguments. But it wouldn't work all of the time : e.g. for GridFlow, it would look like there is a single anything-method taking unlimited unchecked args. Same for all other cross-language interfaces that use class_addanything as little as possible.
You are right. Voting is not a good solution. However, neither is the position of "my format or the highway". However, I suppose it was a mistake to say that we should all have a graphical template to follow and to change all existing help files to it.
I believe in the separation of content and presentation. This has been a major transformation in the world of web since HTML4/CSS, and eventually took root deep into many web frameworks of the decade. It's not a web invention either. It was also deep in the SmallTalk 1980 GUI toolkit, where much of the inspiration came from. In Pd it's not really possible to do the separation, as coordinates are written all over the file format, but the least I can do is make it so that you don't have to position the objects yourself... most of the time.
If I was in your position, I wouldn't want to migrate without a good reason. After all, we all patch differently, we use PD because we love the freedom in how we can work.
It's not just for myself. I believe that the ideas I am putting forward for documentation, are essentially good for everybody.
One possible solution would be that we can at least agree upon what help patches should contain (argument lists, inlet/outlet descriptions etc) and not bother with exact format of "this text goes here, this canvas header is this big and this color, etc".
Let's bother about it, but let's bother about it separately. Layout and colours can go in abstractions where you can change the look of all helpfiles at once (to the extent that the automation has been done. in GridFlow it's perhaps 90% there). The first problem I see with not having a separation, is that people want to finish deciding the look so that they can start writing the docs because once you do it, it's really hard to change the look. That's why PDDP meetings introduced a receive-symbol for changing the colours ; but it didn't introduce abstractions, which are a much more powerful way to deal with the matter.
I remember making the point at PdCon07 that the help browser was confusing to use and I couldn't find the information I wanted (help, references) without going through each folder. A number of people gave me a dismissive look and I don't remember the responses I was given, but they were more along the lines of "it's all there, can't you see?". I got the feeling that since it wasn't a problem for those that had learned the locations of the objects and their names, then it wasn't a problem worth solving. That it was my fault and I should just read more. This did not and still does not sit well with me.
So, what were the solutions that you were proposing, or would have been proposing, or what are the elements of the problem that suggest what kind of solution it could be ?
As far as I know, the pd gui rewrite adds the ability for custom tcl/tk snippets through the command menu. This could be just a tcl call to svn diff.
Ok, so, you have to hunt all over the internet for pieces of tcl code that take 1k each ? Pd has this concept of externals, that are rather plug-and-play (or at least: can be), and then Pd-extended changed the deal and made it no-plug-just-play, and then Pd-devel ("gui-rewrite") would have those snippets of tcl floating around so that you can download your menu-items one by one ? A little bundling would help...
what's the "command menu" ?
Good point. If discussions are not public, we are not obligated to both share and defend our ideas or viewpoints.
Well, it's also that pdpedia is hard to defend. I expect pdpedia to be replaced by something else soon.
In doing so, one has to really give thought into what one is doing.
To give more thought into what one is doing, you need prototypes. Talking and thinking doesn't make one realise all the faults like a prototype does. Discussion better be built around prototypes than what-ifs.
To me, it's the difference between to stating an idea then coding it directly and stating an idea, researching it, presenting it others, getting feedback, and then coding it.
It's a good idea to think about the ability for a design to evolve. That way you can make a prototype early without feeling too guilty about it, and from the prototype you get much feedback that you wouldn't get from conversations, and then you can recycle the prototype into a more long-lasting solution (which would be why you wouldn't be guilty to code early, and why the design ought to be evolvable).
If we don't collaborate effectively, I feel we waste effort individually.
I've come to think of the default as being no collaboration at all, and look at effective collaboration as a form of saving. It's more positive and it conveniently removes the myth of a most perfect collaboration from the equation. The amount of waste is the distance between where we stand and the utmost bestest solution we can't even think of. Frustration doesn't come from this waste, it comes from measuring this waste. In the end, much of this waste doesn't even exist, or assumes unacceptable tradeoffs involving unstated requirements (or otherwise ignored requirements).
Also, we as a community look less active which, for an open source stand point, is not good.
Why would that be, according to you ? I mean why is the community looking less active...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
I've come to think of the default as being no collaboration at all
i knew that and i'd rather this way : http://dontevenreply.com
you're should be proud of your work in this 'community' hey? to destroy it for your own very narrow minded purposes?
sevy
On Jun 5, 2010, at 11:23 AM, Dan Wilcox wrote:
On Jun 5, 2010, at 5:16 PM, Mathieu Bouchard wrote:
On Sat, 5 Jun 2010, Dan Wilcox wrote:
It's nice to see the Pd community can agree upon such basic
conventions.what are you trying to say ?
Nothing personal ... just that I'm annoyed that these are even
issues. Also endless discussions over help formats seem like such
trivialities in the grand scheme of things. Other open source
projects have solved these problems and moved on, will this ever
happen for Pd?Well, whatever. I always seem to start pointless arguments myself.
Couldn't have said it better myself. How about we accept the more
useful, simple conventions like using a patch tracker, and challenge
the more interesting ones?
.hc
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
On Sun, 2010-05-16 at 13:02 -0400, Mathieu Bouchard wrote:
a workaround is to load the patch using
[loadbang] | [delay] | «open my-patch.pd .» | [s pd]
Ah, it was you posting to the bug-tracker ;-) Many thanks for providing this work-around.
Roman
Thank you so much, Mathieu!
You saved my day! Hope somebody will add your "delay" fix to the regular pd / pd-extended distribution.
Ingo
a workaround is to load the patch using
[loadbang] | [delay] | «open my-patch.pd .» | [s pd] _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
It's not that we don't care, maybe it's more that we don't care *as much as you* right now since things are working, but I feel your pain.
Did you check this bug? http://sourceforge.net/tracker/?func=detail&aid=2724318&group_id=557... it relates to -nogui starting up too fast and trying to connect to the sound device *before* port audio is ready for it to do so ...
Sounds like a similar problem I had last year which cause me to go a bit frantic as I was reinstalling my setup on a new Ubuntu (9.04) before a show. Luckily, the following fixed it for me (although I think you guys already tried this ...?).
[delay 100] | |
|; / |pd dsp 1\
Now I am hesitant to upgrade my Ubuntu ...
On May 16, 2010, at 6:13 PM, Ingo Scherzinger wrote:
Looks like not too many people seem to care too much about this. This bug has been around for quite a while. I suppose it's breaking all of the reverbs as well since they are working with stacked delays. I'm wondering if there is anything around to replace [delwrite~] and [delread~] that's currently not broken. Does anybody know of a reverb that works with "-nogui"? I remember there have been some others like [jonverb~] (?) and an abstraction that would replace [freeverb~]. I hope I'll find these. I might have even downloaded them(?). However, I somehow doubt that they will work.
Ingo
hi ingo
what i found out now is mentioned in the issue in the bugtracker
http://sourceforge.net/tracker/?func=detail&aid=2978457&group_id=557... 47
8070 no workaround in the moment. its a pity, cause a project of mine is really waiting to go on air us both, all the best for millers fixing that bug soon
der.brandt
Zitat von "Ingo Scherzinger" ingo@miamiwave.com:
Has anybody figured out the problem with [delwrite~] and [delread~] with
the
-nogui flag?
I'm not getting it to work. And on top of it both my reverbs (freeverb~
fdn~) are not working either anymore. Everything is fine with the gui
turned
on.
I have delayed turning dsp on by 10 seconds already. It doesn't help. I
had
to make an abstraction also to replace [susloop~] which gave up on me
also
with -nogui.
Everything was working fine up until Ubuntu 7.10. With 8.04 and later I started to have problems so I stayed with 7.10 for the -nogui stuff. Now
I
need to get it going with the current OS.
If anybody has found a solution please help me!
Ingo
Dan Wilcox danomatika.com robotcowboy.com
On Mon, 17 May 2010, Dan Wilcox wrote:
Sounds like a similar problem I had last year which cause me to go a bit frantic as I was reinstalling my setup on a new Ubuntu (9.04) before a show. Luckily, the following fixed it for me (although I think you guys already tried this ...?). [delay 100]
You don't need more than just [delay 0], aka [delay] without args.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Sorry, I din't mean to offend anybody about not caring about bugs. It's frustrating when you're not in the position to fix problems like these yourself (because of missing programming skills).
I'm pretty sure that there are still several bugs related to that same problem. Probably caused by the bug Mathieu pointed out with the sampling rate not being initialized correctly. I had this with [susloop~] before. Then I was lucky to write an abstraction with [loop~] to replace it. It's just very difficult (and time consuming) to find the source of these problems since you don't have the graphical representation where you can trace these bugs in "realtime".
I hope there is not too much more of this coming up.
Ingo
It's not that we don't care, maybe it's more that we don't care *as much as you* right now since things are working, but I feel your pain.
Did you check this bug? http://sourceforge.net/tracker/?func=detail http://sourceforge.net/tracker/?func=detail&aid=2724318&group_id=55736&atid =478070 &aid=2724318&group_id=55736&atid=478070 it relates to -nogui starting up too fast and trying to connect to the sound device *before* port audio is ready for it to do so ...
Sounds like a similar problem I had last year which cause me to go a bit frantic as I was reinstalling my setup on a new Ubuntu (9.04) before a show. Luckily, the following fixed it for me (although I think you guys already tried this ...?).
[delay 100]
|
|
|; /
|pd dsp 1\
Now I am hesitant to upgrade my Ubuntu ...
On May 16, 2010, at 6:13 PM, Ingo Scherzinger wrote:
Looks like not too many people seem to care too much about this. This bug has been around for quite a while. I suppose it's breaking all of the reverbs as well since they are working with stacked delays. I'm wondering if there is anything around to replace [delwrite~] and [delread~] that's currently not broken. Does anybody know of a reverb that works with "-nogui"? I remember there have been some others like [jonverb~] (?) and an abstraction that would replace [freeverb~]. I hope I'll find these. I might have even downloaded them(?). However, I somehow doubt that they will work.
Ingo
hi ingo
what i found out now is mentioned in the issue in the bugtracker
http://sourceforge.net/tracker/?func=detail http://sourceforge.net/tracker/?func=detail&aid=2978457&group_id=55736&atid = &aid=2978457&group_id=55736&atid= 47
8070
no workaround in the moment.
its a pity, cause a project of mine is really waiting to go on air
us both, all the best for millers fixing that bug soon
der.brandt
Zitat von "Ingo Scherzinger" ingo@miamiwave.com:
Has anybody figured out the problem with [delwrite~] and [delread~] with
the
-nogui flag?
I'm not getting it to work. And on top of it both my reverbs (freeverb~
fdn~) are not working either anymore. Everything is fine with the gui
turned
on.
I have delayed turning dsp on by 10 seconds already. It doesn't help. I
had
to make an abstraction also to replace [susloop~] which gave up on me
also
with -nogui.
Everything was working fine up until Ubuntu 7.10. With 8.04 and later I
started to have problems so I stayed with 7.10 for the -nogui stuff. Now
I
need to get it going with the current OS.
If anybody has found a solution please help me!
Ingo
Dan Wilcox
danomatika.com
robotcowboy.com
On Mon, 17 May 2010, Ingo Scherzinger wrote:
I’m pretty sure that there are still several bugs related to that same problem. Probably caused by the bug Mathieu pointed out with the sampling rate not being initialized correctly. I had this with [susloop~] before. [...] I hope there is not too much more of this coming up.
[soundfiler~] uses the sys_getsr() command at some point, so, one can assume that there is a bug somewhere in it, for a certain combination of "open", "1", "0", dsp on/off, and [block~].
One may also wonder why would [pique], [bonk~] and [pd~] use sys_getsr() at all.
As far as I can tell, nearly every use of sys_getsr() is a bug at this point. If it doesn't cause a -nogui malfunction, then it causes a [block~] upsampling/downsampling malfunction. Doesn't it ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801