Niko Pettersen

my first post on the forum. I got this one solved but it took a couple of hours as I wasn't

familiar with Attrui behaviour on various routing methods/hierarchy.

The forums somehow didn't allow me to download the maxpatch so it can be found on Drive: https://drive.google.com/file/d/1_szarQyCYY8u8WuyGS_UszwN3WidPF9Q/view?usp=share_link

Let me know if you need the file somewhere else. I tried the upload also without VPN.

For description: In the maxpatch there is a comparison of two routings. When routing the delay~ element with external Number element to message the Delay~with Delay Time it turns out if using Attrui element and routing

2. Number - Delay~and 2.1 Attrui - Delay~ the

The 1. will change Delay~'s Delay Time to ms (instead of samples that were set manually) by force and will display incoming message as ms on the Attrui when Inspected Attribute is set to Delay.

2. and 2.1 are two separate routings and the Attrui or Delay~ doesn't pick the Number as ms even by force as seen in the mstosamps_routing_prob.maxpat.

Attrui being a post to display elements Attributes is the function but this routing to value set problem wasn't represented in any of the literature so it would be welcome to make it impossible to route the 1. way as it doesn't give any advantage for end user experience. 

Person like me with too analytical and punctual mind problems like these bring a certain level of difficulty to comprehend because it just didn't make any sense how the program did behave.

my first post on the forum. I got this one solved but it took a couple of hours as I wasn't
familiar with Attrui behaviour on various routing methods/hierarchy.
The forums somehow didn't allow me to download the maxpatch so it can be found on Drive: https://drive.google.com/file/d/1_szarQyCYY8u8WuyGS_UszwN3WidPF9Q/view?usp=share_link

For description: In the maxpatch there is a comparison of two routings. When routing the delay~ element with external Number element to message the Delay~with Delay Time it turns out if using Attrui element and routing 

1. Number - Attrui - Delay~ 
instead of
2. Number - Delay~and 2.1 Attrui - Delay~ the 

The 1. will change Delay~'s Delay Time to ms (instead of samples that were set manually) by force and will display incoming message as ms on the Attrui when Inspected Attribute is set to Delay.
2. and 2.1 are two separate routings and the Attrui or Delay~ doesn't pick the Number as ms even by force as seen in the mstosamps_routing_prob.maxpat.

Attrui being a post to display elements Attributes is the function but this routing to value set problem wasn't represented in any of the literature so it would be welcome to make it impossible to route the 1. way as it doesn't give any advantage for end user experience. 
Person like me with too analytical and punctual mind problems like these bring a certain level of difficulty to comprehend because it just didn't make any sense how the program did behave.

Hello people,
my first post on the forum. 

can-we-do-something-for-this-delay~attruidelay-time-nasty-issue-especially-for-beginners

image.png

I would suggest you first read delay~ help file

Thanks for your comment. Somehow the picture does only load on my phone.

This doesn't solve the problem I'm after. There's no literature or a mention in the help file about the relative functionality between the Delay~ & Attrui elements as also there is no straight forward answer why the Value Type does change when feeded through the Attrui to the Delay~.

If looking only the picture, it is more of a deduced result.

Thanks for your comment. Somehow the picture does only load on my phone.
This doesn't solve the problem I'm after. There's no literature or a mention in the help file about the relative functionality between the Delay~ & Attrui elements as also there is no straight forward answer why the Value Type does change when feeded through the Attrui to the Delay~.
If looking only the picture, it is more of a deduced result.

Forcing the delay time units to samples is a fallback used when no units are provided. If you want units other than samples, you should append the unit name to the delay time value.

Screenshot 2023-01-06 at 2.49.36 AM.png

Give a look on the routing and see the problem if you haven't checked the maxpatch I provided.

Picture problem.png : https://drive.google.com/file/d/1DkY7NkqrTRRYtlINMNDX17Dn_L9wEDcH/view?usp=share_link

Give a look on the routing and see the problem if you haven't checked the maxpatch I provided.
Picture problem.png : https://drive.google.com/file/d/1DkY7NkqrTRRYtlINMNDX17Dn_L9wEDcH/view?usp=share_link

You should always specify the units, otherwise delay~ defaults to samples.

Screenshot 2023-01-06 at 3.11.45 PM.png

You should always specify the units, otherwise delay~ defaults to samples. 

Thanks. First, I wanted the samples. The specification of unit type will also solve the problem. Still you prove your statement wrong as without specifying the unit to samples, the routing is still a problem as the Delay~ unit says samples to be the default but still it gives on the "wrong" routing the ms as a default unit. Do you see the difference and contradiction with the given information on the Delay~ (delay~: (int/signal) Delay Time in Samples)?

I am curious why this happens as I wasted hours for it. What is the forced hierachy here if there is no apparent reason for the behaviour? Code languages should be written with minimal settings and logic, it is efficient for the processor, but this needs either more routing (+2 connections as seen in the picture) or the specification of the unit ($1). I understand the need for the unit specification in sense of code language philosophy.

mstosamps gives specifically out the number of samples value and the attrui turns them into ms while the next delay~ takes in only sample value information. Where does the ms come from? 

Thanks. First, I wanted the samples. The specification of unit type will also solve the problem. Still you prove your statement wrong as without specifying the unit to samples, the routing is still a problem as the Delay~ unit says samples to be the default but still it gives on the "wrong" routing the ms as a default unit. Do you see the difference and contradiction with the given information on the Delay~ (delay~: (int/signal) Delay Time in Samples)?

I am curious why this happens as I wasted hours for it. What is the forced hierachy here if there is no apparent reason for the behaviour? Code languages should be written with minimal settings and logic, it is efficient for the processor, but this needs either more routing (+2 connections as seen in the picture) or the specification of the unit ($1). I understand the need for the unit specification in sense of code language philosophy.
mstosamps gives specifically out the number of samples value and the attrui turns them into ms while the next delay~ takes in only sample value information. Where does the ms come from? 
Does attrui have it's own default of ms?

Select the objects in your patch, in the main menu select "Edit -> Copy Compressed", then paste right into this text editor. The website will automatically generate a link for download.

Make a partial (crosshair) screenshot and drag or paste the image right into this text editor.

Your routing at the very top of your patch is wrong. You send first the "1000" divisor to the [expr] object and afterwards the Hz value. It has to be the other way around, first the divisor and then the Hz value (Max' right to left rule). Below are two examples, [t] is the short name for the [trigger] object:

grafik-1.png

If you do not need to change the divisor, you can make the conversion in one step:

grafik.png

I do not understand your whole patch and the explanation. You have a Hz value, convert it to ms, then convert it to samples and then want it back as ms to send it to [delay~], which works with samples by default.

You can directly convert to the format you need, here are three examples:

If you want to set either Hz or ms, you can use the method below, for example. The changed value is converted to samples and the other value is silently updated. Don't use this without "set", you would immediately create a loop between the two values (overflow):

Max code to the forum:
Select the objects in your patch, in the main menu select "Edit -> Copy Compressed", then paste right into this text editor.  The website will automatically generate a link for download.

Image to the forum:
Make a partial (crosshair) screenshot and drag or paste the image right into this text editor.

At the beginning of your patch:

Your routing at the very top of your patch is wrong. You send first the "1000" divisor to the [expr] object and afterwards the Hz value. It has to be the other way around, first the divisor and then the Hz value (Max' right to left rule). Below are two examples, [t] is the short name for the [trigger] object:

 
If you want to set either Hz or ms, you can use the method below, for example. The changed value is converted to samples and the other value is silently updated. Don't use this without "set", you would immediately create a loop between the two values (overflow):

Can we do something for this? Delay~+Attrui+Delay Time- Nasty issue especially for beginners