Ableton Forum

dudes dudes. i know how fun it is to attack 3phase, but please leave his thread alone. else, he will start to spread all of those posts into individual threads flooding our whole forum!


actually, i just wanted to say that smiley is AWESOME!

oh, and, you should report it to the safari forum, 3phase. the posters safari rescaled, yours didn't. clearly a bug, report it, post it 10 times!

davepermen wrote:dudes dudes. i know how fun it is to attack 3phase, but please leave his thread alone. else, he will start to spread all of those posts into individual threads flooding our whole forum!


actually, i just wanted to say that smiley is AWESOME!

oh, and, you should report it to the safari forum, 3phase. the posters safari rescaled, yours didn't. clearly a bug, report it, post it 10 times!

note to myself... kill all fanboys

which i'm not. but who cares? note to myself.. kill all haters. because haters gonna hate, no matter what. they are, thanks to this, absolutely useless.

now that was a really huge one, made me crash chrome ..

fx23 wrote:now that was a really huge one, made me crash chrome ..

point 3hase to the Google forums..

133

i miss an all notes of command from within ableton live.. is there one i´ve overseen?
hitting the stop button is no good option on stage...

2,874

arrange view, select a period of time with the loop markers and you can delete time but you have to go to a drop down menu to insert silence.

134

tempo display on warpmarkers is not working propperly.. irritating..

record a clip..insert a warpmarker and move it to the right.. you see the tempo going up !!! but the audio after the warpmarker is staying the same while the portion inbetween that gets stretched becomes actually slower and not faster..

Actualy this rather qualifies as bug..

Problem is that warpmarkers have no consistency which tempo they show.. the tempo before or after the warpmarker..
the first one allways shows the tempo before.. the last one allways the tempo behind.. but when ther is no more warpmarkers and the tempo behind is not changing it should show it like that..but than we dont see taht something is happening? ok..
but when you want to show us a tempo display i would prefer it to count in the wright direction..not possible because the second maker allways looks behind?... sorry your problem..fix that please..


And when you have 3 warp markers the first/start shows the tempo of the audio before the marker... the second and third show the tempo of the audio after the marker...

Now move marker 2 the one in the middle..it changes the tempo to show you what happens after the marker.. ..

and the section inebetween? what is the tempo betwen the first and the second warp marker?

sorry..you have to stick to one rule here ..either a warpmaker shows the tempo after the maker..or before.. ..this cant change around all the time

that the the single warper szenario shows bullshit clearly illustrates this..

maybe do a split tempo info. while moving the warpmarker.. leftof it you show the tempo of the section before the maker,, and on the right you show the tempo after it... that would give a good overview about the edit..

so when you move the warpmarker from left to right.. the tempo on the left decreases while the tempo on the right increases, understood poser and depperman?


Question remains..what tempo do we see in the clipeditor when we click on a maker..


I opt for the tempo after the marker..from this point its this tempo....and this allways no exclusion for the first marker....

with an extra info window while performing the warp you domt need to mess with the tempo displayed in the clip editor..

135 3phase can't spell my name

but yeah, i understood your point, and actually noticed it. not, that i have a problem with it, but you described it well (better than your bug reports, much more detailed), and it sure is inconsistent.

davepermen wrote:135 3phase can't spell my name

but yeah, i understood your point, and actually noticed it. not, that i have a problem with it, but you described it well (better than your bug reports, much more detailed), and it sure is inconsistent.

i reportet that in the beta bug forum allready many month ago and i am sure that the abes know about it..

it however belongs in the list because it is getting in my way on a regular basis and one of the details that is prone to share the destiny of some other little things that got shifted to the back of the to do list, in favor of more important tasks for years and years , up to the moment they was not on the to do list anymore..

as said, never got in my way, but a good point for the list.

135


lives tempoatomation dont allows text input... or? and he tempo resolution is too rough for certain tasksits debatable wether one needs 4 digits after the dot.. but 2 is too rough whn you need to fine pitch/allign to ecternal materials

"tempautomation" sounds cool

136

maybe i allready metioned i allready... after tempochages the program likes to keep tha samplerate conversion o sometimes..
so one cant really trust ableton live for mastering purposes...

it would be good when ther would be an trusty idicator when the clips SRC is active.. also reminds users to avoid it when possible

137

when you switch wap off the loop state in/off dont gets memorized so you allways have to reanable the loop again..

not very important..but actually the mighty computer could just fall back to its las state when switching it on again.

138

Bpm input to clips is not possible withe mouse.. when you have a clip at 120 bpm and change that setting with the mouse you cant go back to the original tempo..it offers you only the option to set the tempo on 120.11 or 119.85... in general you cant set straight numbers as bpm values with the mouse. would be good to have it getting straight bpm values or maybe have a fine resultion with the apple key like the volume faders..

its also an intersting questin if 120.11 bpm set with the mouse are really 12.11 and not 120.1178 bpm ..because lives internal tempo resolution is higher than the one you can input.. what is in my opinion anyway a tactical mistake that might lead to brown henke dither. THE resolution of 4 digits is for some taskes anyway not high enough,, again in the syncing department.. to run things in free sync with SRC active you sometimes need 4 digits bpm resolution to have long enough periouds of time running tight enough to get clean running loops.. Not often needed but with logic the 4 digit resolution is a feature i use regulary over the years..