antwan

So I'm trying to form a full understanding of [zigzag~] here. What I'm looking for is to first setup the list step by step and only have it trigger on my later command. So I'm working in mode 1, triggering zigzag's list with a signal click to the left input. I understand this much:

1) sending a list to the first inlet also triggers itself immediately, this i don't want.

2) i see i can use setindex to modify values of indices without zigzag~ outputting anything, good.

why does for instance the insert-message also trigger some output. How do i for instance create new indices (insert) without zigzag~ outputting anything? Feels weird I can't do that.

Thanks for any insights. I'm running 5.1.1 btw.

1) sending a list to the first inlet also triggers itself immediately, this i don't want.
2) i see i can use setindex to modify values of indices without zigzag~ outputting anything, good.

modifying-zigzags-list-without-output

I agree. This is annoying and most likely an oversight on my part, but I don't think it's going to change soon. There actually might be existing patches actually rely on this behavior.

The easiest way to work around this would be to set the speed input to zero and then set to one when you want to trigger the envelope.

I agree. This is annoying and most likely an oversight on my part, but I don't think it's going to change soon. There actually might be existing patches actually rely on this behavior. 

The easiest way to work around this would be to set the speed input to zero and then set to one when you want to trigger the envelope. 

Yes I suppose that is a possible workaround. Although I do agree it's only a workaround and against my logic concerning zigzag operation, it does take care of the problem pretty well. The only remaining annoyance I find at the moment is that there is no mode of operation that would allow for this scenario:

Let's say I have a a list like this: 0. 0 1. 5000 0. 5000 (i.e. a 10000ms envelope)

Then I trigger the list and let it run past the second point, ie. index 1 (1. 5000).

As it's progressing towards the last index I add a point right inbetween the first and second point (lets say 0.5 2500 and the old index 1 hence becomes 1. 2500 if we're maintaining whole envelope's total length).

What happens is, basically the envelope in progress jumps back a quarter of the way, because clearly the zigzag progress is always based on current index. And since I add a new Index 1 just as it's going from the old Index 1 towards the old Index 2, it jumps back. Long story short I guess: a mode of operation in which progress is based on milliseconds (as represented in the list) would be great because then you could be doing changes on the first half of the envelope while it's still playing back the latter half, for example.

And thanks for your reply.
Yes I suppose that is a possible workaround. Although I do agree it's only a workaround and against my logic concerning zigzag operation, it does take care of the problem pretty well. The only remaining annoyance I find at the moment is that there is no mode of operation that would allow for this scenario:

Let's say I have a a list like this: 0. 0 1. 5000 0. 5000      (i.e. a 10000ms envelope)
Then I trigger the list and let it run past the second point, ie. index 1 (1. 5000).
As it's progressing towards the last index I add a point right inbetween the first and second point (lets say 0.5 2500 and the old index 1 hence becomes 1. 2500 if we're maintaining whole envelope's total length).

I thought I had this part figured out but apparently not. What would be your insight on a signal-rate way to "open and close" the speed input upon triggering and envelope completion? Below is what I thought would do it but it doesn't work for one reason or another.

And another question:
I thought I had this part figured out but apparently not. What would be your insight on a signal-rate way to "open and close" the speed input upon triggering and envelope completion? Below is what I thought would do it but it doesn't work for one reason or another.

Yeah, this is all super lame, but as mentioned, not likely to change anytime soon. I guess I would do something like the following message sequence: speed 0, append , jumpend, speed 1. This would leave the end value outputting until next trigger, but otherwise is hopefully acceptable.

I believe this issue is not fixed yet. Or is it?

I'm on Max6, and no matter how long I tried, I could not get to define a ramp without zigzag outputting it.

This is happening in mode 1 while a signal is connected to zigzag~

+1 on this. even just having a "set" message for this would be great.

I found out this solution by using the "setindex" message which allows you to update the ramp information (values and transition-times) by accessing each index individually without triggering out the envelope.

modifying zigzag~'s list without output