No problem. :-)
By the way, I had a look at the source code and Miller actually included a
routine to check for a possible block size mismatch, but at the moment it
doesn't do much and the error message is surpressed:
-----------------------------------------------------------------------------------------
/* routine to check that all delwrites/delreads/vds have same vecsize */
static void sigdelwrite_checkvecsize(t_sigdelwrite *x, int vecsize)
{
if (x->x_rsortno != ugen_getsortno())
{
x->x_vecsize = vecsize;
x->x_rsortno = ugen_getsortno();
}
/*
LATER this should really check sample rate and blocking, once that is
supported. Probably we don't actually care about vecsize.
For now just suppress this check. */
#if 0
else if (vecsize != x->x_vecsize)
pd_error(x, "delread/delwrite/vd vector size mismatch");
#endif
}
-----------------------------------------------------------------------------------------------
Gesendet: Sonntag, 13. Dezember 2015 um 21:40 Uhr
Von: "Alexandre Torres Porres" <[email protected]>
An: "Christof Ressi" <[email protected]>
Cc: "[email protected]" <[email protected]>
Betreff: Re: Re: Re: Re: Re: [PD] 0 length delay in delwrite~
> So I'm quite astonished that you're accusing me of throwing
> around with apodictic statements
you're right, I was too harsh
sorry
2015-12-13 16:37 GMT-02:00 Christof Ressi <[email protected]>:> just think
outside your mind a little, think about other people that are not you...
I'm just giving my personal opinion. I can understand that you want to have
more things working 'under the hood' and I'm in the opposite camp. But that's
fine and as always the truth lies in the middle. If Miller decides that
[delwrite~] should check for the block sizes of all the [delread] objects,
that's perfectly fine for me.
No matter how stuff is implemented, the most important thing is that it's fully
documented. I agree that Pd should be as accessible as possible, but that's
mostly a matter of documentation.
> why would you insist in saying things are unnecessary just because you don't
> mind doing it
I'm giving personal opinions and I'm clearly marking them as such (adding
phrases like "I think", "in my opinion"). So I'm quite astonished that you're
accusing me of throwing around with apodictic statements.
Gesendet: Sonntag, 13. Dezember 2015 um 19:09 Uhr
Von: "Alexandre Torres Porres" <[email protected][[email protected]]>
An: "Christof Ressi" <[email protected][[email protected]]>
Cc: "Miller Puckette" <[email protected][[email protected]]>,
"[email protected][[email protected]]"
<[email protected][[email protected]]>
Betreff: Re: Re: Re: Re: [PD] 0 length delay in delwrite~
Well, it's just a matter of opinion, you think it's unnecessary and I couldn't
disagree more, we could just get it over with :)
But tell me, deep inside, if it did just work without you bothering with
anything, would that be a problem to you? Cause it'd be a huge relief for me...
It's not even for me, I guess I could live with that, but I teach Pd for almost
a decade now, I know something about newcomers... I'm an advocate of Pd and I
try to make it as accessible and easy as possible, and I'd really have a
problem with telling them (well, you gotta worry about all this stuff because
there is a mentality in the Pd world that it'd be "unnecessary" for this to be
automatically worked out for the user).
My life in Pd world is mostly devoted to teaching and advocating Pd as an user
friendly tool, it has this power...
just think outside your mind a little, think about other people that are not
you... why would you insist in saying things are unnecessary just because you
don't mind doing it - do you mind *not* doing it? What would you lose? Why
making a case out of it?
well, again, in the end, it's a matter of opinion, but as a tie-breaking
criteria, I think that making it easier for more people and more user friendly
should count.
cheers
2015-12-13 15:54 GMT-02:00 Christof Ressi
<[email protected][[email protected]]>:> add a bunch of samples to the
delay ; work that internally
In a way, I agree on that, just add 64 samples so everything works for trivial
use cases at block size 64. If you're using delay lines with other block sizes
you're doing advanced stuff anyway.
> why live so hard?
Given that everything is documented cleanly, there's no higher math involved in
getting the right buffer size, just a multiplication and a subtraction ;-).
> That doesn't seem crazy, get them all, check their block size, stay with the
> greater block size, work it out interbally, voilà...
> all the worries are over. Not too crazy and just elegant simple coding.
> You're treating this as a mission impossible where it's quite trivial to me.
I never said it's a mission impossible. I just said it's unnecessary. If
[delwrite~] has fixed buffer size, why should it constantly change only because
I change the block size in some subpatch? To me this sounds rather absurd. It's
not like that we don't have to care about a lot things on our own (just think
of fft subpatches!).
Gesendet: Sonntag, 13. Dezember 2015 um 18:34 Uhr
Von: "Alexandre Torres Porres"
<[email protected][[email protected]][[email protected][[email protected]]]>
An: "Christof Ressi"
<[email protected][[email protected]][[email protected][[email protected]]]>
Cc: "Miller Puckette"
<[email protected][[email protected]][[email protected][[email protected]]]>,
"[email protected][[email protected]][[email protected][[email protected]]]"
<[email protected][[email protected]][[email protected][[email protected]]]>
Betreff: Re: Re: Re: [PD] 0 length delay in delwrite~
> At least we all agree that there's a mismatch between
> the docs and the actual behaviour.
that's a start
In my opinion, being able to use [delwrite~] and [delread~] at different
blocksizes is a nice feature, so what about a nice little warning in the docs
that you have to care about the buffer size if you're using different
blocksizes?
Even failing to see how one thing prevents the other, my point is that you need
to care about buffer size ALL OF THE TIME... it's never Good.
And in my point of view, it's just so simple: add a bunch of samples to the
delay ; work that internally
Of course Miller could add some complicated mechanism for [delwrite~] to keep
track of all the block sizes of its [delread~] objects.
That doesn't seem crazy, get them all, check their block size, stay with the
greater block size, work it out interbally, voilà... all the worries are over.
Not too crazy and just elegant simple coding. You're treating this as a mission
impossible where it's quite trivial to me.
, but to me the simplest solution is updating the docs and stating: "max.
delay time = buffer size - block size of [delread~]"
Might be "simpler", but the craziest, and also the laziest, turning the user
and patching experience into a nightmare. You're asking us to check all the
block sizes and do the math ourselves and then convert it to ms and then insert
it into a delwrite~ object... why live so hard?
cheers
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
