info@krispenhartung.com

I'm having some difficult getting my delay feedback parameter to work properly in my max/msp patch when I build it to a .dll. Everything else works as I expect. For one, if you view my patcher below, you'll see that I had to use 1000. as a max. value argument for the pp object that shows/configures the feedback parameter...that was the only way I could get the fader to move all the way across, verus only a small sliver of the way if I used 1.as the max. value (which is what the feedback value maxes out as when I control it in the patcher).

Second, the feedback is behaving radically in the plug...if I even try to increase it, it launches into what appears to be an infinite feedback loop and howls like a wolf. It is as if the Feedback slider is on or off 0 feedback or 1.

Any clues or tips? If I could just see someone's delay patch and how they configured feedback, I'd be able to figure it out. I went through the entire Pluggo developer tutorial, and didn't get the info I need to resolve my problem.

I'm having some difficult getting my delay feedback parameter to work properly in my max/msp patch when I build it to a .dll. Everything else works as I expect. For one, if you view my patcher below, you'll see that I had to use 1000. as a max. value argument for the pp object that shows/configures the feedback parameter...that was the only way I could get the fader to move all the way across, verus only a small sliver of the way if I used 1.as the max. value (which is what the feedback value maxes out as when I control it in the patcher). 

Second, the feedback is behaving radically in the plug...if I even try to increase it, it launches into what appears to be an infinite feedback loop and howls like a wolf.  It is as if the Feedback slider is on or off 0 feedback or 1.

Any clues or tips?  If I could just see someone's delay patch and how they configured feedback, I'd be able to figure it out. I went through the entire Pluggo developer tutorial, and didn't get the info I need to resolve my problem.

getting-delay-feedback-to-work-from-patcher-to-plugin

On 01 Oct 2006, at 17:20, Krispen Hartung wrote:

> Second, the feedback is behaving radically in the plug...if I even 

> try to increase it, it launches into what appears to be an infinite 

> feedback loop and howls like a wolf. It is as if the Feedback 

no wonder if you scale the fb within a range of 0 to 1000 integer 

check the range of the slider you are using.

in this case you could just scale the output of the slider to get a 

On 01 Oct 2006, at 17:20, Krispen Hartung wrote:
>
> Second, the feedback is behaving radically in the plug...if I even  
> try to increase it, it launches into what appears to be an infinite  
> feedback loop and howls like a wolf.  It is as if the Feedback  
> slider is on or off 0 feedback or 1.

no wonder if you scale the fb within a range of 0 to 1000 integer  
values.
check the range of the slider you are using.
in this case you could just scale the output of the slider to get a  
0. to 1. range, i.e. multiply by 0.001.


Thanks. I think I follow you. So, it is back to the original way I had it 

configured, with a twist. So, I leave the argument max in the pp object for 

FB as 1000. to allow the fader to slide all the way, but after the fader add 

an * .001. box after the fader, and before going back to the audio network 

itself, namely the *~ objects after the tapout. Did I get this right, or are 

you suggesting that I not use 1000., which would lead me back to the fader 

I think the mistake I made before is that I would dividing by 1000 after the 

fader...which also yields 1. or the actual max value of the FB. Why wouldn't 

Quote: vb wrote on Sun, 01 October 2006 09:36

----------------------------------------------------

> On 01 Oct 2006, at 17:20, Krispen Hartung wrote:

> > Second, the feedback is behaving radically in the plug...if I even 

> > try to increase it, it launches into what appears to be an infinite 

> > feedback loop and howls like a wolf. It is as if the Feedback 

> no wonder if you scale the fb within a range of 0 to 1000 integer 

> check the range of the slider you are using.

> in this case you could just scale the output of the slider to get a 

> 0. to 1. range, i.e. multiply by 0.001.

Thanks. I think I follow you. So, it is back to the original way I had it 
configured, with a twist. So, I leave the argument max in the pp object for 
FB as 1000. to allow the fader to slide all the way, but after the fader add 
an * .001. box after the fader, and before going back to the audio network 
itself, namely the *~ objects after the tapout. Did I get this right, or are 
you suggesting that I not use 1000., which would lead me back to the fader 
not sliding all the way across.

I think the mistake I made before is that I would dividing by 1000 after the 
fader...which also yields 1. or the actual max value of the FB. Why wouldn't 
that work?

Quote: vb wrote on Sun, 01 October 2006 09:36
----------------------------------------------------
>
> On 01 Oct 2006, at 17:20, Krispen Hartung wrote:
> >
> > Second, the feedback is behaving radically in the plug...if I even  
> > try to increase it, it launches into what appears to be an infinite  
> > feedback loop and howls like a wolf.  It is as if the Feedback  
> > slider is on or off 0 feedback or 1.
>
> no wonder if you scale the fb within a range of 0 to 1000 integer  
> values.
> check the range of the slider you are using.
> in this case you could just scale the output of the slider to get a  
> 0. to 1. range, i.e. multiply by 0.001.
>
----------------------------------------------------


well, as always, there's more than one way.

fact is, that the slider you are using, is integer only.

but you want to control a parameter, which has a float range of 0. to 1.

so, either you scale the output of the slider, or use a slider, that 

if you want to stick to your integer slider, then yes, you have to 

give the same range to the pp as to the slider.

otherwise you won't be able to move the slider to it's full range. if 

no need for floats, though, integers are fine here: [pp 6 fb 0 1000] 

> I think the mistake I made before is that I would dividing by 1000 

> fader...which also yields 1. or the actual max value of the FB. Why 

ok, there is an important difference between integers and floats, 

if you make an integer division [/ 1000] your result will always be 

an integer, and that is no good if you want to end up with a range of 

[/ 1000.] (dividing by a float) would have worked in your case.

well, as always, there's more than one way.
fact is, that the slider you are using, is integer only.
but you want to control a parameter, which has a float range of 0. to 1.
so, either you scale the output of the slider, or use a slider, that  
can handle floats (e.g. multislider).

if you want to stick to your integer slider, then yes, you have to  
give the same range to the pp as to the slider.
otherwise you won't be able to move the slider to it's full range. if  
you think about it, this makes sense.
no need for floats, though, integers are fine here: [pp 6 fb 0 1000]  
or whatever.

> I think the mistake I made before is that I would dividing by 1000  
> after the
> fader...which also yields 1. or the actual max value of the FB. Why  
> wouldn't
> that work?

ok, there is an important difference between integers and floats,  
watch out for that.
if you make an integer division [/ 1000] your result will always be  
an integer, and that is no good if you want to end up with a range of  
0. to 1.
[/ 1000.] (dividing by a float) would have worked in your case.

>ok, there is an important difference between integers and floats,

One of THE most basic features of Max is the 

difference between ints and floats [for the

literate and curious, see the Overview chapter

of the Fundamentals manual, or "Getting Started"

if you're oldskool)]. In essence Max objects 

that perform calculations assume that they're

working on integers UNLESS you tell them otherwise,

and they'll always truncate any fractional portion

of a number on output. Use arguments [+ 1.] or

[pack 1. 2 3.] to set an object to perform and

output floating point numbers. After that, you're

>ok, there is an important difference between integers and floats,
>watch out for that.

One of THE most basic features of Max is the 
difference between ints and floats [for the
literate and curious, see the Overview chapter
of the Fundamentals manual, or "Getting Started"
if you're oldskool)]. In essence Max objects 
that perform calculations assume that they're
working on integers UNLESS you tell them otherwise,
and they'll always truncate any fractional portion
of a number on output. Use arguments [+ 1.] or
[pack 1. 2 3.] to set an object to perform and
output floating point numbers. After that, you're
good to go.


yes!!! You just made my day. I won't be making that mistake again. Everything works perfectly now, after changing the min and max values to 0 and 1000 and removing the multiplication after the fader. Thank you.

It's funny, for really simple mistakes like this, most people just say read the MAX/MXP documentation, such and such section, page n of 600 pages, etc. I'm always confident this is the case, but when you are learning this stuff for the first time, the documetation is like drinking from a firehose...the human brain can only retain so much information before applying it in small chunks. So thanks for helping me out here with your tip, rather than just saying something to make me feel like a dumb ass, because I have't read and completely absorbed several hundres pages regarding a very complex piece of software. The cool thing is that I WILL retain this tip, because I just applied it after going through exactly 30 revisions of my patcher, and learning by trial and error.

Quote: vb wrote on Sun, 01 October 2006 10:40

> well, as always, there's more than one way.

> fact is, that the slider you are using, is integer only.

> but you want to control a parameter, which has a float range of 0. to 1.

> so, either you scale the output of the slider, or use a slider, that 

> if you want to stick to your integer slider, then yes, you have to 

> give the same range to the pp as to the slider.

> otherwise you won't be able to move the slider to it's full range. if 

> no need for floats, though, integers are fine here: [pp 6 fb 0 1000] 

> > I think the mistake I made before is that I would dividing by 1000 

> > fader...which also yields 1. or the actual max value of the FB. Why 

> ok, there is an important difference between integers and floats, 

> if you make an integer division [/ 1000] your result will always be 

> an integer, and that is no good if you want to end up with a range of 

> [/ 1000.] (dividing by a float) would have worked in your case.

Quote: vb wrote on Sun, 01 October 2006 10:40
----------------------------------------------------
> well, as always, there's more than one way.
> fact is, that the slider you are using, is integer only.
> but you want to control a parameter, which has a float range of 0. to 1.
> so, either you scale the output of the slider, or use a slider, that  
> can handle floats (e.g. multislider).
>
> if you want to stick to your integer slider, then yes, you have to  
> give the same range to the pp as to the slider.
> otherwise you won't be able to move the slider to it's full range. if  
> you think about it, this makes sense.
> no need for floats, though, integers are fine here: [pp 6 fb 0 1000]  
> or whatever.
>
> > I think the mistake I made before is that I would dividing by 1000  
> > after the
> > fader...which also yields 1. or the actual max value of the FB. Why  
> > wouldn't
> > that work?
>
> ok, there is an important difference between integers and floats,  
> watch out for that.
> if you make an integer division [/ 1000] your result will always be  
> an integer, and that is no good if you want to end up with a range of  
> 0. to 1.
> [/ 1000.] (dividing by a float) would have worked in your case.
>
> volker.
>
----------------------------------------------------


Quote: Gregory Taylor wrote on Sun, 01 October 2006 11:19

> One of THE most basic features of Max is the 

> difference between ints and floats [for the

> literate and curious, see the Overview chapter

> of the Fundamentals manual, or "Getting Started"

yeah, I read this document, Gregory. But it was theoretical at the time, and the solution did not jump out at me when working on this patch. So being literate in this case wasn't to my advantage. I sincerely hope your subtle comment wasn't a slam. Honestly, it's very discouraging to be told constantly to read the manuals, as if that is always the one and only obvious solution to the problem. That statement has many assumptions built into it, and given that MAX experts appear to be very logical minded and sharp when it comes to deductions and inferences (that is a compliment, btw), I'm guessing it also comes with an appreciation that reading doesn't imply knowledge, and knowledge doesn't always imply practical application of solutions. I can chart this out in symbolic logic, if you like, so we can plug the variables in. :)

Quote: Gregory Taylor wrote on Sun, 01 October 2006 11:19
----------------------------------------------------
>
> One of THE most basic features of Max is the 
> difference between ints and floats [for the
> literate and curious, see the Overview chapter
> of the Fundamentals manual, or "Getting Started"
> if you're oldskool)]. 

yeah, I read this document, Gregory. But it was theoretical at the time, and the solution did not jump out at me when working on this patch.  So being literate in this case wasn't to my advantage. I sincerely hope your subtle comment wasn't a slam. Honestly, it's very discouraging to be told constantly to read the manuals, as if that is always the one and only obvious solution to the problem. That statement has many assumptions built into it, and given that MAX experts appear to be very logical minded and sharp when it comes to deductions and inferences (that is a compliment, btw), I'm guessing it also comes with an appreciation that reading doesn't imply knowledge, and knowledge doesn't always imply practical application of solutions. I can chart this out in symbolic logic, if you like, so we can plug the variables in. :)

On Oct 1, 2006, at 12:45 PM, Krispen Hartung wrote:

> yeah, I read this document, Gregory. But it was theoretical at the 

> time, and the solution did not jump out at me when working on this 

> patch. So being literate in this case wasn't to my advantage. I 

> sincerely hope your subtle comment wasn't a slam. Honestly, it's 

> very discouraging to be told constantly to read the manuals, as if 

> that is always the one and only obvious solution to the problem.

No slam intended. It's not the ONE solution, but - to

the extent that any number of us have done our

jobs well - it IS an obvious one. There certainly are

places where things aren't documented at all, or

not documented well [we're working on that in

addition to other things with respect to the next

version of Max, so feel free to point them out],

Although we talk about Max as a programming

environment, it has many of the same features as

a language - things like orderly rules for processing

things, ways of categorizing messages, and so on.

It's certainly true that some things - like separable

verbs in a Germanic language, for example - may

seem theoretical early on, It never hurts to assume

that the grammar book and the dictionary on your

deak might be of some use to you, and to assume

it early on. It's a question of efficiency, if nothing

You've discovered that you have apparently missed

something that's kind of basic [and, now that you

know it, you probably won't forget it]. Perhaps this

would be a good opportunity to wonder what else

you might have missed and to rescan the Fundamentals

with fresh eyes - or wiser ones, in your case. Now

that you're further along, perhaps things will seem

less theoretical or hypothetical. And nearly everyone

who goes through the Fundamentals comes out with

a bunch of new shortcuts or things they didn't know.

Heck, I edit and write bits of the thing, and I still find

stuff I either don't know or have forgotten. :-)

> yeah, I read this document, Gregory. But it was theoretical at the  
> time, and the solution did not jump out at me when working on this  
> patch.  So being literate in this case wasn't to my advantage. I  
> sincerely hope your subtle comment wasn't a slam. Honestly, it's  
> very discouraging to be told constantly to read the manuals, as if  
> that is always the one and only obvious solution to the problem.

No slam intended. It's not the ONE solution, but - to
the extent that any number of us have done our
jobs well - it IS an obvious one. There certainly are
places where things aren't documented at all, or
not documented well [we're working on that in
addition to other things with respect to the next
version of Max, so feel free to point them out],
but this really isn't one of them.

Although we talk about Max as a programming
environment, it has many of the same features as
a language - things like orderly rules for processing
things, ways of categorizing messages, and so on.
It's certainly true that some things - like separable
verbs in a Germanic language, for example - may
seem theoretical early on, It never hurts to assume
that the grammar book and the dictionary on your
deak might be of some use to you, and to assume
it early on. It's a question of efficiency, if nothing
else.

You've discovered that you have apparently missed
something that's kind of basic [and, now that you
know it, you probably won't forget it]. Perhaps this
would be a good opportunity to wonder what else
you might have missed and to rescan the Fundamentals
with fresh eyes - or wiser ones, in your case. Now
that you're further along, perhaps things will seem
less theoretical or hypothetical. And nearly everyone
who goes through the Fundamentals comes out with
a bunch of new shortcuts or things they didn't know.
Heck, I edit and write bits of the thing, and I still find
stuff I either don't know or have forgotten. :-)

good points. I will re-read the fundamentals! You are right, it is as if when you learn by experience and trial and error, it prepares you to be more receptive to the documentation, and visa versa...both feed off of each other. It's a pretty sappy analogy, but it's like reading a romance novel (which I hate), going out and living it for real, and then going back to read the novel...and then it's "oh, that's what they meant by....." :)

Quote: Gregory Taylor wrote on Sun, 01 October 2006 12:18

> On Oct 1, 2006, at 12:45 PM, Krispen Hartung wrote:

> > yeah, I read this document, Gregory. But it was theoretical at the 

> > time, and the solution did not jump out at me when working on this 

> > patch. So being literate in this case wasn't to my advantage. I 

> > sincerely hope your subtle comment wasn't a slam. Honestly, it's 

> > very discouraging to be told constantly to read the manuals, as if 

> > that is always the one and only obvious solution to the problem.

> No slam intended. It's not the ONE solution, but - to

> the extent that any number of us have done our

> jobs well - it IS an obvious one. There certainly are

> places where things aren't documented at all, or

> not documented well [we're working on that in

> addition to other things with respect to the next

> version of Max, so feel free to point them out],

> Although we talk about Max as a programming

> environment, it has many of the same features as

> a language - things like orderly rules for processing

> things, ways of categorizing messages, and so on.

> It's certainly true that some things - like separable

> verbs in a Germanic language, for example - may

> seem theoretical early on, It never hurts to assume

> that the grammar book and the dictionary on your

> deak might be of some use to you, and to assume

> it early on. It's a question of efficiency, if nothing

> You've discovered that you have apparently missed

> something that's kind of basic [and, now that you

> know it, you probably won't forget it]. Perhaps this

> would be a good opportunity to wonder what else

> you might have missed and to rescan the Fundamentals

> with fresh eyes - or wiser ones, in your case. Now

> that you're further along, perhaps things will seem

> less theoretical or hypothetical. And nearly everyone

> who goes through the Fundamentals comes out with

> a bunch of new shortcuts or things they didn't know.

> Heck, I edit and write bits of the thing, and I still find

> stuff I either don't know or have forgotten. :-)

good points. I will re-read the fundamentals!  You are right, it is as if when you learn by experience and trial and error, it prepares you to be more receptive to the documentation, and visa versa...both feed off of each other. It's a pretty sappy analogy, but it's like reading a romance novel (which I hate), going out and living it for real, and then going back to read the novel...and then it's "oh, that's what they meant by....." :)

Quote: Gregory Taylor wrote on Sun, 01 October 2006 12:18
----------------------------------------------------
>
> On Oct 1, 2006, at 12:45 PM, Krispen Hartung wrote:
>
> > yeah, I read this document, Gregory. But it was theoretical at the  
> > time, and the solution did not jump out at me when working on this  
> > patch.  So being literate in this case wasn't to my advantage. I  
> > sincerely hope your subtle comment wasn't a slam. Honestly, it's  
> > very discouraging to be told constantly to read the manuals, as if  
> > that is always the one and only obvious solution to the problem.
>
> No slam intended. It's not the ONE solution, but - to
> the extent that any number of us have done our
> jobs well - it IS an obvious one. There certainly are
> places where things aren't documented at all, or
> not documented well [we're working on that in
> addition to other things with respect to the next
> version of Max, so feel free to point them out],
> but this really isn't one of them.
>
> Although we talk about Max as a programming
> environment, it has many of the same features as
> a language - things like orderly rules for processing
> things, ways of categorizing messages, and so on.
> It's certainly true that some things - like separable
> verbs in a Germanic language, for example - may
> seem theoretical early on, It never hurts to assume
> that the grammar book and the dictionary on your
> deak might be of some use to you, and to assume
> it early on. It's a question of efficiency, if nothing
> else.
>
> You've discovered that you have apparently missed
> something that's kind of basic [and, now that you
> know it, you probably won't forget it]. Perhaps this
> would be a good opportunity to wonder what else
> you might have missed and to rescan the Fundamentals
> with fresh eyes - or wiser ones, in your case. Now
> that you're further along, perhaps things will seem
> less theoretical or hypothetical. And nearly everyone
> who goes through the Fundamentals comes out with
> a bunch of new shortcuts or things they didn't know.
> Heck, I edit and write bits of the thing, and I still find
> stuff I either don't know or have forgotten. :-)
>
> Win-win.
>
----------------------------------------------------


> the human brain can only retain so much information before applying

Especially if you do it in the speed you do it at the moment ;-)

A note to the slider range of 1000. You do get higher resolution and you 

need that for setting the delay time for example. But you probably 

recognized, that moving the slider with the mouse is kind of sticky. 

That's because the sliderrange is finer than the pixel resolution. It 

feels a bit "strange" If you do not need the high resolution, the 

standard size of 128 isn't bad and moves more smoothly with the mouse.

The feedback level does not need this resolution if you apply the more 

intuitive decibels. just use dbtoa and atodb to apply this...

Krispen Hartung wrote:
> the human brain can only retain so much information before applying
> it in small chunks.

A note to the slider range of 1000. You do get higher resolution and you 
need that for setting the delay time for example. But you probably 
recognized, that moving the slider with the mouse is kind of sticky. 
That's because the sliderrange is finer than the pixel resolution. It 
feels a bit "strange" If you do not need the high resolution, the 
standard size of 128 isn't bad and moves more smoothly with the mouse.
The feedback level does not need this resolution if you apply the more 
intuitive decibels. just use dbtoa and atodb to apply this...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


Getting Delay Feedback to work from patcher to plugin