petition: tighten move playing position in M4L
-
- Posts: 118
- Joined: Thu Nov 18, 2004 7:26 pm
- Contact:
Re: petition: tighten move playing position in M4L
thats a good point, and i appreciate that there is a lot going on here. I can only hope for genius and innovation from the ableton krew...code hard folks, your work is appreciated!
i drop on the lokeymassive
-
- Posts: 7
- Joined: Sun Sep 13, 2009 10:52 pm
Re: petition: tighten move playing position in M4L
Bump it! any news?
Re: petition: tighten move playing position in M4L
Bump again. Any news from the developers?
Re: petition: tighten move playing position in M4L
+1 from me too!
-
- Posts: 7
- Joined: Mon Nov 23, 2009 9:33 am
- Contact:
Re: petition: tighten move playing position in M4L
+1 from my side
Re: petition: tighten move playing position in M4L
A buffer~ stores its samples in the RAM, this is why I would suggest to not create buffers which are too long.
The clips are mainly read from HD, so loading the clip in RAM does help, but does not solve the ridiculous problem of the difficulty in setting sub loop points, and the even more ridiculous issue of not being able to distinguish from Loop start and end points and Sample start and end points, which are quite different in definition.
I had to invent such workarounds for this that I decided that it s MUCH better and safer to use a combination of buffer/stutter to do exactly what I would like and theoretically could do already with the m4l combination.
There is really a lot of redundancy in Live which I think is a pain in the *** .
I do not care that a sound file looped is reproduced in time with the 4/4 Timeline and keeps the thing in the back, I just want it to start when I want, and to be in sync... simple like this.
If then the zillion users who actually use Live as a Playstation need it, then give the possibility of having a profi version of Live, and a consumer version.
Sometimes I really don´t get it, well most times.
so + 74
The clips are mainly read from HD, so loading the clip in RAM does help, but does not solve the ridiculous problem of the difficulty in setting sub loop points, and the even more ridiculous issue of not being able to distinguish from Loop start and end points and Sample start and end points, which are quite different in definition.
I had to invent such workarounds for this that I decided that it s MUCH better and safer to use a combination of buffer/stutter to do exactly what I would like and theoretically could do already with the m4l combination.
There is really a lot of redundancy in Live which I think is a pain in the *** .
I do not care that a sound file looped is reproduced in time with the 4/4 Timeline and keeps the thing in the back, I just want it to start when I want, and to be in sync... simple like this.
If then the zillion users who actually use Live as a Playstation need it, then give the possibility of having a profi version of Live, and a consumer version.
Sometimes I really don´t get it, well most times.
so + 74
sound spatialization content & technologies @ audit-orium.com
Re: petition: tighten move playing position in M4L
Do you think one day this move playing position issue could be fixed?
Waiting this for month!
Waiting this for month!
Re: petition: tighten move playing position in M4L
As I understand it, the problem is due to inaccuracy of observing the playing_position since observers are polled at an interval of about 50ms.
So with the current concept of observers there is no solution I guess.
So with the current concept of observers there is no solution I guess.
Re: petition: tighten move playing position in M4L
@broc
would this implementation of the observers explain the timing problems between live and max for live? it sounds as if a possible solution would be to significantly decrease the polling interval...which may of course adversely affect performance.
anyway, just trying to get a better understanding of the problem to see if this problem can ever be resolved
would this implementation of the observers explain the timing problems between live and max for live? it sounds as if a possible solution would be to significantly decrease the polling interval...which may of course adversely affect performance.
anyway, just trying to get a better understanding of the problem to see if this problem can ever be resolved
Re: petition: tighten move playing position in M4L
Yes, a smaller interval can improve accuracy, but any interval above sample rate would induce timing errors. I think that observers are just not suited for time-critical operations. On the other hand, there is a [timepoint] object for the global timeline that triggers a bang at any specified position. Perhaps something similar could also be implemented for individual clips..tchan wrote:@broc
would this implementation of the observers explain the timing problems between live and max for live? it sounds as if a possible solution would be to significantly decrease the polling interval...which may of course adversely affect performance.
anyway, just trying to get a better understanding of the problem to see if this problem can ever be resolved
Re: petition: tighten move playing position in M4L
would this need to be implemented in live itself or can this be done in max for live? it's good to know what can be causing the problem...but as an end-user it's a little frustrating. most of us simply have no idea what it's going to take to make these changes...nor the unintended performance consequences that may arise with any proposed solution. we just want all these cool patches to work as best they canbroc wrote:there is a [timepoint] object for the global timeline that triggers a bang at any specified position. Perhaps something similar could also be implemented for individual clips..
Re: petition: tighten move playing position in M4L
Well, I could only speculate on technical details and consequences.tchan wrote:would this need to be implemented in live itself or can this be done in max for live? it's good to know what can be causing the problem...but as an end-user it's a little frustrating. most of us simply have no idea what it's going to take to make these changes...nor the unintended performance consequences that may arise with any proposed solution. we just want all these cool patches to work as best they canbroc wrote:there is a [timepoint] object for the global timeline that triggers a bang at any specified position. Perhaps something similar could also be implemented for individual clips..
So at this point we'd really need a comment from the developers.
Re: petition: tighten move playing position in M4L
Please ableton team and ableton developers, have a look inside this issue !
-
- Posts: 4
- Joined: Thu Dec 10, 2009 8:24 pm
Re: petition: tighten move playing position in M4L
I wonder why no response from the gang. Tighten it up, boys, or let us know to try other means of chopping.