|
|
|
09-04-2015, 12:43 PM
|
#1
|
Human being with feelings
Join Date: Dec 2012
Posts: 13,333
|
v5.02pre3 - September 4 2015
v5.02pre3 - September 4 2015
+ API: added OpenColorThemeFile(), GetLastColorThemeFile()
+ API: added OpenMediaExplorer()
+ FX: optimized/hardened parameter automation notification code
+ Time display: fixed measures/beats time display when in preroll before t=0
# Selection: fixed marquee item/envelope point selection not obeying some locking options
# Selection: fixed select all tracks/envelope points vs some locking options [p=1538248]
# Snap offset: fixed rounding in action to snap to nearest grid
# VST: re-enabled disabled notetrackers
|
|
|
09-04-2015, 03:19 PM
|
#2
|
Human being with feelings
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,793
|
Quote:
Originally Posted by vitalker
v5.02pre3 - September 4 2015
+ API: added OpenMediaExplorer()
|
Media Explorer API options would be wonderful so the extension developers can worth their magic. My understanding is that since it's a plugin and not part of the core program additional functionality can only be added by Cockos (i.e. not SWS)...
__________________
FRs: v5 Media Explorer Requests, Global Quantization, Session View
Win10 Pro 64-bit, Reaper 6(x64), AMD 3950x, Aorus X570 Master, 64GB DDR4 3600, PowerColor Red Devil 5700XT, EVO 970 2TB, 10TB HD, Define R6
|
|
|
09-04-2015, 04:11 PM
|
#3
|
Human being with feelings
Join Date: Jun 2009
Location: South, UK
Posts: 14,214
|
Quote:
Originally Posted by PitchSlap
Media Explorer API options would be wonderful so the extension developers can worth their magic. My understanding is that since it's a plugin and not part of the core program additional functionality can only be added by Cockos (i.e. not SWS)...
|
That would be amazing.
I'm sure if that happened, I would then be able to pay good money to whoever creates something that can search metadata for SFX libraries.
__________________
subproject FRs click here
note: don't search for my pseudonym on the web. The "musicbynumbers" you find is not me or the name I use for my own music.
|
|
|
09-05-2015, 03:17 AM
|
#4
|
Human being with feelings
Join Date: Nov 2008
Location: London, UK
Posts: 2,581
|
Errm, what's going on here, hmm?
MIDI edits aren't committed when MIDI Editor is closed. Spotted just now in 5.02pre2 and confirmed in 5.02pre3, also.
https://stash.reaper.fm/v/25035/BUG_M...dont_stick.RPP
|
|
|
09-05-2015, 03:32 AM
|
#5
|
Human being with feelings
Join Date: Jun 2015
Location: Indonesia Raya
Posts: 684
|
Quote:
Originally Posted by daxliniere
|
it's working when MIDI editor docked. i tried to reproduced the bug with your *.RPP seems working just fine by docking/undocking MIDI editor.
|
|
|
09-05-2015, 03:37 AM
|
#6
|
Human being with feelings
Join Date: Nov 2008
Location: London, UK
Posts: 2,581
|
Quote:
Originally Posted by jrengmusic
it's working when MIDI editor docked. i tried to reproduced the bug with your *.RPP seems working just fine by docking/undocking MIDI editor.
|
Thanks jrengmusic. Were you able to reproduce the bug shown? As I read it, you were able to reproduce it, then found the temporary workaround to be docking and undocking the MIDI editor. Do I understand you correctly?
|
|
|
09-05-2015, 03:38 AM
|
#7
|
Human being with feelings
Join Date: Jun 2015
Location: Indonesia Raya
Posts: 684
|
Quote:
Originally Posted by daxliniere
Thanks jrengmusic. Were you able to reproduce the bug shown? As I read it, you were able to reproduce it, then found the temporary workaround to be docking and undocking the MIDI editor. Do I understand you correctly?
|
yes, like so
|
|
|
09-05-2015, 03:39 AM
|
#8
|
Human being with feelings
Join Date: Nov 2008
Location: London, UK
Posts: 2,581
|
Great, thanks
|
|
|
09-05-2015, 04:13 AM
|
#9
|
Human being with feelings
Join Date: Jun 2007
Location: Terra incognita
Posts: 7,670
|
Quote:
Originally Posted by daxliniere
Errm, what's going on here, hmm?
MIDI edits aren't committed when MIDI Editor is closed. Spotted just now in 5.02pre2 and confirmed in 5.02pre3, also.
|
Did you resize the item earlier?
resizing MIDI items shifts notes positions ?
http://forum.cockos.com/showthread.php?t=143255
Moving midi note not sample accurate
http://forum.cockos.com/showthread.php?t=151876
|
|
|
09-05-2015, 04:26 AM
|
#10
|
Human being with feelings
Join Date: Nov 2008
Location: London, UK
Posts: 2,581
|
Quote:
Originally Posted by xpander
Did you resize the item earlier?
|
I believe so.
EDIT: I looked into both of those links you gave, Xpander, but neither of them seem to be the same problem as this.
Last edited by daxliniere; 09-05-2015 at 04:35 AM.
|
|
|
09-05-2015, 09:16 AM
|
#11
|
Human being with feelings
Join Date: Jun 2007
Location: Terra incognita
Posts: 7,670
|
Well I was looking for a way to reproduce this phenomenon and the first topic I linked to discusses one possible way. Interesting note that the project marker you have in there is also not aligned strictly to the "zero" grid and neither are the note starts nor the item itself. Once the start of the item is snapped to grid, the note starts will do it also. Docking/undocking the editor does nothing to the notes here.
|
|
|
09-05-2015, 09:42 AM
|
#12
|
Human being with feelings
Join Date: Jun 2015
Location: Indonesia Raya
Posts: 684
|
Quote:
Originally Posted by xpander
Docking/undocking the editor does nothing to the notes here.
|
It does nothing to the notes. But, it make the MIDI editor committed when closed.
|
|
|
09-05-2015, 10:27 AM
|
#13
|
Human being with feelings
Join Date: Jun 2007
Location: Terra incognita
Posts: 7,670
|
If the quest in this case is to make the note starts to align with the grid line, undocking/docking the MIDI editor doesn't make a difference here. I have to do something specific to the item/notes to get them to align and undocking/docking is not needed to commit that edit, that's what I'm saying. And something else has happened, which may be the question, to make this problem to appear in the first place.
Last edited by xpander; 09-05-2015 at 10:35 AM.
|
|
|
09-05-2015, 10:43 PM
|
#14
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,721
|
Quote:
Originally Posted by daxliniere
|
You're making edits that are less than 1 MIDI tick long, which will temporarily display for purposes of editing, but won't actually commit (they are converted to integer ticks at that point). This isn't a bug, just a limitation in the midi resolution you're using. You could try changing your ticks per QN to something like 96000 if it really bothers you, though it's probably unnecessary.
|
|
|
09-05-2015, 10:58 PM
|
#15
|
Human being with feelings
Join Date: Nov 2008
Location: London, UK
Posts: 2,581
|
Quote:
Originally Posted by Justin
You're making edits that are less than 1 MIDI tick long
|
All I'm trying to do is put the note on the bar line.
Is it possible to make REAPER snap MIDI edits to ticks in the same way you can snap audio to project sample rate?
It's a bit misleading at the moment as it makes it seem like you have more precision than you actually do.
Last edited by daxliniere; 09-05-2015 at 11:08 PM.
|
|
|
09-05-2015, 11:07 PM
|
#16
|
Human being with feelings
Join Date: Oct 2008
Location: Right Hear
Posts: 15,618
|
64 bit.. on win 7
I don't find that midi note problem... 'not saving or updating..' when the ME closes...
In fact I see them update on the item in the arrange window, even with the ME still open, so by the time it closes they are already done... I don't think I used to see that happen so well...
|
|
|
09-05-2015, 11:09 PM
|
#17
|
Human being with feelings
Join Date: Nov 2008
Location: London, UK
Posts: 2,581
|
Also, why is this affected by docking/undocking?
|
|
|
09-06-2015, 12:44 AM
|
#18
|
Human being with feelings
Join Date: Jun 2012
Location: Spain
Posts: 7,239
|
I have tried this old bug in 5.02pre3 and is still happening and increasing the ticks to 9600 doesn't help. I don't think it is a display issue because it is actually modifying the note position?
I think it only happens when the midi item is not looped, and it is worse when you zoom in more in the arrange before moving the edge.
testing in 5.02pre3 win7 x64:
edit: increasing the ticks per quarter note for new MIDI items does help. I didn't read that it is for new MIDI items. It seems that after increasing ticks to 9600, this is only for new items created. Now it works better, the notes are still displayed incorrectly, but the number position doesn't change.
Last edited by heda; 09-06-2015 at 12:54 AM.
|
|
|
09-06-2015, 02:14 AM
|
#19
|
Human being with feelings
Join Date: Dec 2008
Posts: 2,111
|
Quote:
Originally Posted by heda
edit: increasing the ticks per quarter note for new MIDI items does help. I didn't read that it is for new MIDI items. It seems that after increasing ticks to 9600, this is only for new items created. Now it works better, the notes are still displayed incorrectly, but the number position doesn't change.
|
But increasing ticks per quarter note does not help to get a correct sound. Incorrectly shifting note positions can produce comb filtered sounds when layering MIDI tracks.
Even with ticks set to 96000 you can easily hear the comb filtering for example by using two ReaSynth tracks playing the same note.
Here is a simple test project:
https://stash.reaper.fm/25044/midi_note_shift_error.RPP
jnif
Last edited by jnif; 09-06-2015 at 02:52 AM.
|
|
|
09-06-2015, 04:21 AM
|
#20
|
Human being with feelings
Join Date: Dec 2008
Posts: 2,111
|
Quote:
Originally Posted by Justin
You're making edits that are less than 1 MIDI tick long, which will temporarily display for purposes of editing, but won't actually commit (they are converted to integer ticks at that point). This isn't a bug, just a limitation in the midi resolution you're using. You could try changing your ticks per QN to something like 96000 if it really bothers you, though it's probably unnecessary.
|
How about adding an option (enabled by default) to always snap MIDI item edges to MIDI tick grid?
I think that would solve lot of problems like those reported by daxliniere and heda.
It looks like currently the MIDI tick grid is used only for events inside MIDI items. But there should be also a project-wide MIDI tick grid where MIDI items are snapped.
jnif
|
|
|
09-06-2015, 05:15 AM
|
#21
|
Human being with feelings
Join Date: Oct 2007
Location: home is where the heart is
Posts: 12,096
|
Quote:
Originally Posted by Justin
You're making edits that are less than 1 MIDI tick long, which will temporarily display for purposes of editing, but won't actually commit (they are converted to integer ticks at that point).
|
Gotta say, I don't see the sense of this (at first glance).
Why being able to edit something (in between ticks) if it doesn't commit anyway ?
Always snapping edits to ticks as has been suggested by dax also seems the better option to me in this case.
But maybe I'm missing something.
Last edited by nofish; 09-06-2015 at 05:20 AM.
|
|
|
09-06-2015, 06:15 AM
|
#22
|
Human being with feelings
Join Date: Apr 2014
Posts: 943
|
I find this very obscure/suspicious that some people begin to speak
about such basic understanding things like musical timebase events
notated of course in ticks base on
1 pulse length in µs = 60.000.000 : (BPM*PPQN)
1 tick remains always 1 tick(the same like notes on paper 1/4 remains 1/4)
And so the tempo can easy change by the app, one device and or the musican....
and not like Audio Samples fixed to time.
Or notated someone a 1/4 note lenght on paper in ms or µs
1 tick is of course the smallest unit but it has base on time and others than AudioSampleEvent an variable time lenght.
----------
Simply remove this stupid fixed 100th stuff view at all ruler and change it
as it should with musical timebase events to
measure.beat.ticks
or maybe
measure.beat.sig.quarter ticks
base on the PPQN in prefs
Otherwise it brings only rounding errors and of course such graphical things like above or simply confusing/misunderstandings.
-----------
9600... no 10000 it is 100th base
ruler view 1.1.9999
otherwise you get of course also rounding problems ....
PS
Grid Snap to ticks is really missing
BTW 64/128/256/512/1024 .....PPQN has advantages
Grid
1/256 | 1/512 | 1/1024 | 1/2048 | 1/4096
and you have an exact 1 tick snap in the editor
I never really understood why the hell 48/96/120/192/240/384/480/960 ppqn
Maybe the root was the max transmission rate of MIDI DIN 31250baud /0.32 ms byte /0.96 ms per 3 byte voice message
__________________
I hope you can understand me? Without german beer my written english is always very bad, with beer it becomes unbearable!.
Less is more! To much limited the own creativity.
Last edited by ELP; 09-06-2015 at 08:11 AM.
|
|
|
09-06-2015, 06:52 AM
|
#23
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
|
Quote:
Originally Posted by ELP
I never really understood why the hell 48/96/192/384/480/960 ppqn
Maybe the root was the max transmission rate of MIDI DIN 31250baud /0.32 ms byte /0.96 ms per 3 byte voice message
|
Yeah, that.
|
|
|
09-06-2015, 10:58 AM
|
#24
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
Quote:
Originally Posted by ELP
Simply remove this stupid fixed 100th stuff view at all ruler and change it
as it should with musical timebase events to
measure.beat.ticks
or maybe
measure.beat.sig.quarter ticks
base on the PPQN in prefs
|
MIDI editor -> Options: "Time format for ruler": Measure.beats.MIDI-ticks. Only for MIDI editor ruler and event list, though.
Actually back in the days I was strongly supporting the introduction of this option, but soon after found myself using the 1/100 setting, just because it's nicer to calculate for my decimal-shaped braincell, even if it isn't exactly what happens...
Quote:
Originally Posted by ELP
I never really understood why the hell 48/96/120/192/240/384/480/960 ppqn
Maybe the root was the max transmission rate of MIDI DIN 31250baud /0.32 ms byte /0.96 ms per 3 byte voice message
|
I believe the thinking is to have numbers that can be divided by many divisors like 2,3,4,6,8,12,16,24 so that as many common musical divisions as possible (including triplets, sextoles etc, but sacrificing less common quintoles and the like on the way) can be quantized to whole ticks.
Last edited by gofer; 09-06-2015 at 11:14 AM.
|
|
|
09-06-2015, 11:27 AM
|
#25
|
Banned
Join Date: Jun 2015
Location: Lower Rhine Area, DE
Posts: 964
|
Quote:
Originally Posted by ELP
...
I never really understood why the hell 48/96/120/192/240/384/480/960 ppqn
Maybe the root was the max transmission rate of MIDI DIN 31250baud /0.32 ms byte /0.96 ms per 3 byte voice message
|
that and you could do micro-triplets and really precise normal triplets. every value can be divided by 2 and by 3.
thats the explanation from Yamaha in manuals for thingies from the early 90s, such as QY-10 and so on.
|
|
|
09-06-2015, 11:53 AM
|
#26
|
Human being with feelings
Join Date: Jan 2010
Location: Kalispell
Posts: 14,745
|
Quote:
Originally Posted by gofer
I believe the thinking is to have numbers that can be divided by many divisors like 2,3,4,6,8,12,16,24 so that as many common musical divisions as possible (including triplets, sextoles etc, but sacrificing less common quintoles and the like on the way) can be quantized to whole ticks.
|
I think you're right gofer, at least it makes sense.
I personally don't have a problem with the way it works as long as it snaps to grid in the ME. At 960 tpqn, it's just slightly over half a millisecond between ticks. I don't think anyone is going to feel any differences with that resolution, which to me is the most important thing.
However, I might be missing the point here.
|
|
|
09-06-2015, 12:56 PM
|
#27
|
Human being with feelings
Join Date: Apr 2014
Posts: 943
|
"MIDI editor -> Options: "Time format for ruler": Measure.beats.MIDI-ticks. Only for MIDI editor ruler and event list, though..."
Yes of course gofer but all other are 100th... arrange , transport, item propertie position etc.pp and there is no option to change this
to -for musical timebase really better-
Measure.beats.tick view.
As you can see the result is such discussions/bug reports or whatever
for naturally occurring visual and also rounding "errors" together with 100th.
The resizing of the item(start means left posi. without snap)
and this moving events to back within the item (which is reported)
is for me the result/sum of many rounding errors -together with 100th, high zoom etc.pp.
Maybe I'm totally wrong but I do not think so, because
the Delta Time for events begin independently for each item at the start(left) position of the item.,---
But ok i personally never ever resize MIDI items left & without snap. why should i do that.
So i mean maybe better really remove the 100th stuff or add an option for all ruler.
Including transport bar and properties etc. pp
100th is simply not MTB-like and Measure.beats.tick should be default.
"LightOfDay : 2 and by 3; gofer: divided by many divisors...; EvilDragon: Yeah, that. "
Yep probably all played a role.
But for staight, dotted and also triplet etc. pp
then the values
96/192/384/768 for ppqn
are clearly the better choice instead of
120/240/480/960 ppqn
Which explained very well the
magic number 15360 PPQN
Multiples of ...48/96/192/384/768/1536/3072
&
...60/120/240/480/960/1920/3840/7680
and also ...32/64/128/256/512/1024
__________________
I hope you can understand me? Without german beer my written english is always very bad, with beer it becomes unbearable!.
Less is more! To much limited the own creativity.
Last edited by ELP; 09-07-2015 at 08:56 AM.
|
|
|
09-06-2015, 01:43 PM
|
#28
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
I am not against a measure/beats/tick ruler and transport, but wouldn't use it personally. I just don't care enough. I don't even care abut whether the resolution is 960, as long as it is fine enough for me to not feel a difference between a note being on one tick or the next. With a ppq of 96 as my old AKAI had, I could feel it at least with slow tempi, but at 960 I certainly don't. So the division by plenty of small numbers is really just a mathematical matter for me. In practical terms I wouldn't feel any worse or better if I set ppq to a round 1000 and had forced uneven triplets (if I would quantize which I don't, so my stuff ain't even anyway ). I probably wouldn't feel much difference with ppq of 500...
This kind of discussion really seems obscure to me. Even when I can't have my MIDI be sample accurately lined up to audio, it's just not enough to be heard (by me), provided I don't line up the exact same sound to the audio in which case I'd get phasing issues. I don't know why I should do that, though, so the problem just doesn't exist in my practice.
Dax' issue has more to do with what Jnif said, that MIDI items can start between MIDI ticks, so he can't get his note to start at exactly the grid line. I can relate to that this is irritating to see, but I don't think I'd ever actually feel or hear that offset. Nevertheless I think I would enable the option to have MIDI items always start at a project wide tick resolution, just to not get that offset visually.
|
|
|
09-06-2015, 02:18 PM
|
#29
|
Human being with feelings
Join Date: Apr 2014
Posts: 943
|
Yes I feel the same gofer obscure^^
But now for me its more an:
If you do it then do it right.
mathematical matter or not.
And 100th can result in integer rounding errors
+89 89: 90 30 60
normally at Delta Time 0 ...
High zoom & some more left item resizing without snap -within arrange
and ...schwups nothing is more as it should.
__________________
I hope you can understand me? Without german beer my written english is always very bad, with beer it becomes unbearable!.
Less is more! To much limited the own creativity.
Last edited by ELP; 09-06-2015 at 02:38 PM.
|
|
|
09-06-2015, 03:13 PM
|
#30
|
Human being with feelings
Join Date: Feb 2008
Location: Mesa, AZ
Posts: 2,057
|
Quote:
Originally Posted by gofer
he can't get his note to start at exactly the grid line. I can relate to that this is irritating to see
|
If the note is not at the gridline won't that potentially cause ever-increasing offsetting when duplicating/copying?
__________________
Soundemote - Home of the chaosfly and pretty oscilloscope.
MyReaperPlugin - Easy-to-use cross-platform C++ REAPER extension template
|
|
|
09-06-2015, 04:10 PM
|
#31
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
Quote:
Originally Posted by ELP
And 100th can result in integer rounding errors
+89 89: 90 30 60
normally at Delta Time 0 ...
High zoom & some more left item resizing without snap -within arrange
and ...schwups nothing is more as it should.
|
If you mean this bug: http://forum.cockos.com/showthread.php?t=143255, then yes, I do have the feeling it's related, but don't think it would be cured by merely displaying ticks in the ruler (if you don't snap to them). It would probably be fixed by snapping MIDI item edges to ticks, though (whether displayed or not). But who am I to know?
@ Argitoth, didn't try, but only if the item length isn't a multiple of bar length, methinks.
|
|
|
09-06-2015, 04:15 PM
|
#32
|
Human being with feelings
Join Date: Jan 2010
Location: Kalispell
Posts: 14,745
|
Quote:
Originally Posted by ELP
Yep probably all played a role.
But for staight, dotted and also triplet etc. pp
then the values
96/192/384/768 for ppqn
are clearly the better choice instead of
120/240/480/960 ppqn
|
Yes, that seems to be the case.
Although 960 works very well with all with all divisions, clearly the sequence of 96, 192, 384, 768, 1536, 3072 works better over all.
|
|
|
09-06-2015, 07:10 PM
|
#33
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,721
|
dax, why not align the start of the midi source at an even beat boundary, it's positioned arbitrarily now...
|
|
|
09-06-2015, 08:28 PM
|
#34
|
Human being with feelings
Join Date: Nov 2008
Location: London, UK
Posts: 2,581
|
Hi Justin,
It's fine, but thanks, I got the problem solved in under 30 seconds. I lost more time reporting the problem than on the problem itself.
Th inability to move those notes is a symptom of a problem, not the cause, which is why I reported it.
Workarounds are just that.
An impossible result should not be offered to the user as a possibility, which is why I'm suggesting this bug/issue should be addressed.
|
|
|
09-07-2015, 04:15 AM
|
#35
|
Human being with feelings
Join Date: Jul 2012
Location: Netherlands
Posts: 5,247
|
Dear peoples !
I am using 5.02pre3-64bit on OSX 10.10.5.
In Reaper prefs, i have setup "Tail length when using apply fx to items" set to 2000 ms
I have an item on a Track with (only) Reverb FX plugin in Track's FX chain, the item is selected.
I execute action: Apply Track/Take FX to Items.
now, the tail of the reverb is not printed ; the printed item has the same length of the original ..
I am just starting to use Apply Track/Take FX to Items, so maybe i am doing something wrong.
I tried with different reverb plugins, no difference.
Is this maybe a 5.02pre3 issue (on mac) ?
Hope to hear from you !
|
|
|
09-07-2015, 05:33 AM
|
#36
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,749
|
Quote:
Originally Posted by vanhaze
now, the tail of the reverb is not printed ; the printed item has the same length of the original ..
|
The rendered source media should be 2 seconds longer than the original. Drag the right side of the media item to the right in order to reveal the tail audio.
|
|
|
09-07-2015, 06:12 AM
|
#37
|
Human being with feelings
Join Date: Nov 2010
Posts: 2,436
|
Wouldn't setting PPQ to a number that is the least common multiple of 96 and 256 (768 in this case) be an optimal solution?
That way you know PPQ is divisible both by 96 and 256, 128, 64 etc...
|
|
|
09-07-2015, 07:11 AM
|
#38
|
Human being with feelings
Join Date: Jul 2012
Location: Netherlands
Posts: 5,247
|
Hey schwa, just checked that and indeed, you are right !
However, i find this abit cumbersome and illogical.
Would logically have thought that the trail would be visible immediately in the Item.
Is there maybe a way (action ?) that can reveil the trail instantly ?
|
|
|
09-07-2015, 07:43 AM
|
#39
|
Human being with feelings
Join Date: Nov 2008
Location: London, UK
Posts: 2,581
|
Quote:
Originally Posted by vanhaze
However, i find this abit cumbersome and illogical.
Would logically have thought that the trail would be visible immediately in the Item.
|
Hey Vanhaze,
It actually does make sense; think about the scenario where you apply an FX chain (don't think reverbs/delays for now) onto an item which has crossfaded edges. You would expect that item to retain the original length, right?
Having said that, it should be pretty easy to make a script which runs 'Apply Track/Take FX to Items' then resizes the item by 2 seconds (or, even better, resizes it to the maximum extent of the item).
|
|
|
09-07-2015, 08:04 AM
|
#40
|
Human being with feelings
Join Date: Jul 2012
Location: Netherlands
Posts: 5,247
|
Sorry, haven't thought of that, you are right.
However for the custom action i made, as shown in this vid, it WAS nice to see the item showing it's original length:
https://youtu.be/UbUOEdGcG9Q
In this script, i used the action : "Set item length to source media length"
Pretty handy action imho.
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 01:58 PM.
|