maxDelayTime 过长有什么害处？
What's the harm in having a long maxDelayTime?
我正在构建一个使用多个延迟节点的实时循环应用程序。我通过将 maxDelayTime 设置为略长于 delayTime 来初始化延迟节点，因为这似乎是正确的做法。我不知道它是否真的有所作为，但将 maxDelayTime 设置为例如 maxDelayTime 似乎很浪费。 3 分钟，而我只需要延迟 10-15 秒。
但是，我希望用户能够调整循环的大小，而这正是我遇到问题的地方。如果用户希望循环更小，我可以将 delayTime 设置为更小的数字，一切都很好。但是，用户不能使循环变大，因为不能覆盖 maxDelayTime。我可以用适当的 maxDelayTime 重新创建所有延迟节点，但是延迟节点连接 to/from 一堆其他节点，所以我不想重新创建整个节点。
所以我的问题是：
即使延迟时间通常小于 30 秒，创建 8 个 maxDelayTime 为 3 分钟的延迟节点是否是个坏主意，以防万一用户想要进行更长的循环？
是的，这是个坏主意。
考虑这一点的最佳方式是 maxDelayTime 设置不断更新的内部缓冲区的大小——delayTime 只是改变该缓冲区中的查找点。如果您将 maxDelay 设置得过大，您将消耗大量内存（例如，立体声 44.1kHz 中的 8 个延迟节点和 3 分钟的 maxDelay 将占用大约 496 兆字节。在移动设备上，这是数量巨大。（即使在台式机上，也相当多。）
我可能会围绕一些换出新节点的拐点设置边界 - 例如>30 秒，>2 分钟 - 并为这些尺寸设置 maxDelay。例如，如果您的默认值为 30 秒，则您的 8 个节点为 "only" 82 meg.
我正在构建一个使用多个延迟节点的实时循环应用程序。我通过将 maxDelayTime 设置为略长于 delayTime 来初始化延迟节点，因为这似乎是正确的做法。我不知道它是否真的有所作为，但将 maxDelayTime 设置为例如 maxDelayTime 似乎很浪费。 3 分钟，而我只需要延迟 10-15 秒。
但是，我希望用户能够调整循环的大小，而这正是我遇到问题的地方。如果用户希望循环更小，我可以将 delayTime 设置为更小的数字，一切都很好。但是，用户不能使循环变大，因为不能覆盖 maxDelayTime。我可以用适当的 maxDelayTime 重新创建所有延迟节点，但是延迟节点连接 to/from 一堆其他节点，所以我不想重新创建整个节点。
所以我的问题是：
即使延迟时间通常小于 30 秒，创建 8 个 maxDelayTime 为 3 分钟的延迟节点是否是个坏主意，以防万一用户想要进行更长的循环？
是的，这是个坏主意。
考虑这一点的最佳方式是 maxDelayTime 设置不断更新的内部缓冲区的大小——delayTime 只是改变该缓冲区中的查找点。如果您将 maxDelay 设置得过大，您将消耗大量内存（例如，立体声 44.1kHz 中的 8 个延迟节点和 3 分钟的 maxDelay 将占用大约 496 兆字节。在移动设备上，这是数量巨大。（即使在台式机上，也相当多。）
我可能会围绕一些换出新节点的拐点设置边界 - 例如>30 秒，>2 分钟 - 并为这些尺寸设置 maxDelay。例如，如果您的默认值为 30 秒，则您的 8 个节点为 "only" 82 meg.