|
|
|
07-21-2009, 06:04 PM
|
#1
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
Geezer (FIXED)
I wasn't sure where to put this so I put it here. Keep in mind the midi drum track being split here is only 2:30 long.
No offense to whoever wrote this code block but this thing is a dog. Imagine a classical producer splitting a very long midi drum track and thinking... "wtf?".
40 seconds to split up a 2.5 minute drum track. Not good.
Same file in Cubase... (or I suspect most any sequencer)...
Point being once Reaper starts adding advanced midi editing that parses though thick streams of notes to do something it needs to be faster than this or it will be ... not good.
Last edited by Lawrence; 07-21-2009 at 06:19 PM.
|
|
|
07-21-2009, 06:34 PM
|
#2
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
I also looked at the split by channel function. Same thing. These are the only two functions I can find (so far) that deep dive into the midi data from the arranger screen and do something like this and they're really slow.
I can't recall ever seeing a progress bar when editing midi data before. It goes without saying that this kind of thing is instantaneous in every sequencer I've ever used.
This one is more confusing than the other one since on import if you select to split it by channel it's instantaneous... bam... it's there. But once it's on a track in the daw it takes this really slow code to split it up. It leads one to think that the internal storage handling of midi data is very inefficient.
It does not bode well for advanced midi editing from the timeline.
This is insane. It's only 37kb of midi data total.
Last edited by Lawrence; 07-21-2009 at 07:16 PM.
|
|
|
07-21-2009, 07:21 PM
|
#3
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
The mystery continues.
Looking at the performance meter when doing those operations it seems that they only use one core. It shouldn't really matter since it should only take a second or two but given how long this takes, and seeing how it's application modal (you can't do anything else until it finishes anyway) why not use all cores and go as fast as possible?
That's all.
|
|
|
07-21-2009, 07:24 PM
|
#4
|
Human being with feelings
Join Date: Jun 2006
Posts: 22,572
|
excellent observations.
can anyone else repro?
|
|
|
07-21-2009, 08:04 PM
|
#5
|
Human being with feelings
Join Date: Jul 2006
Posts: 12,482
|
Quote:
Originally Posted by Lawrence
This is insane. It's only 37kb of midi data total.
|
Why don't you just upload such midi file?
|
|
|
07-21-2009, 08:20 PM
|
#6
|
Human being with feelings
Join Date: Mar 2008
Location: Sydney, Australia
Posts: 3,955
|
Quote:
Originally Posted by Lawrence
The mystery continues.
Looking at the performance meter when doing those operations it seems that they only use one core. It shouldn't really matter since it should only take a second or two but given how long this takes, and seeing how it's application modal (you can't do anything else until it finishes anyway) why not use all cores and go as fast as possible?
That's all.
|
doesn't look like the sort of function that's easily parallelizable so i wouldn't expect it to be able to go multicore without lots of hard work.
but it looks like that IS really slow. i'd suggest uploading the midi file in question and i reckon they'll get a fix for it soon, there might be some sort of special case in there that's slowing down their code.
|
|
|
07-21-2009, 08:24 PM
|
#7
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
Quote:
Originally Posted by Dstruct
Why don't you just upload such midi file?
|
Standard midi files are a dime a dozen on the internet, just grab one and try it yourself. Any standard midi file will do.
http://www.hamienet.com/
Never mind... I zipped up some here in the attached file.
Last edited by Lawrence; 11-26-2010 at 09:21 AM.
|
|
|
07-21-2009, 08:26 PM
|
#8
|
Human being with feelings
Join Date: Jul 2006
Posts: 12,482
|
Last edited by Dstruct; 08-03-2009 at 03:18 AM.
|
|
|
07-21-2009, 08:29 PM
|
#9
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
Quote:
Originally Posted by dub3000
i'd suggest uploading the midi file in question and i reckon they'll get a fix for it soon, there might be some sort of special case in there that's slowing down their code.
|
Nah, it's the same with any midi file. At least every one I tried it with, the behavior is pretty much the same. Again, that was only a 2.5 minute song.
4 minute jazz song - Drums: 37 seconds.
Seal - Kiss From a Rose - 4:30 Drums: 53 seconds. Only 8 different pitches in the entire track to split.
Point being (partly) that midi composers will sometimes play chords on the piano and then copy and split the notes to separate tracks and send them to woodwinds, brass, etc, etc. So it's not just drums.
My personal concern is when features get added like "Cut/paste B3 & C6 from track X to new track Y" from the timeline - those kinds of advanced editing features that parse the data - that they might take 30 seconds to execute and just be a real pain in the ass to use.
Last edited by Lawrence; 07-21-2009 at 08:45 PM.
|
|
|
07-21-2009, 08:43 PM
|
#10
|
Human being with feelings
Join Date: Jul 2006
Location: Hungary
Posts: 3,129
|
random .mid:
explode by channels takes approx 0.5 sec here, but then exploding all the channels by pitch takes exactly 1 minute on my Core2Duo notebook.
definitely slow, i can confirm it.
__________________
panda in the desert
|
|
|
07-21-2009, 08:46 PM
|
#11
|
Human being with feelings
Join Date: Jun 2007
Posts: 204
|
Great spotting!
Even an empty MIDI event can take a long time to process, which indicates that something is certainly sluggish in slothville. Would be nice to have this working optimally.
|
|
|
07-21-2009, 08:47 PM
|
#12
|
Human being with feelings
Join Date: Jun 2006
Posts: 22,572
|
confirmed.
|
|
|
07-21-2009, 08:47 PM
|
#13
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
Quote:
Originally Posted by beatbybit
random .mid:
explode by channels takes approx 0.5 sec here, but then exploding all the channels by pitch takes exactly 1 minute on my Core2Duo notebook.
definitely slow, i can confirm it.
|
Explode by channel from the timeline from a single track? Or explode by channel on file import? Import an SMF of a cover song with 6-8-10 tracks or more and don't (uncheck the option) split it on import. Then explode it manually by channel.
|
|
|
07-21-2009, 08:51 PM
|
#14
|
Super Moderator (no feelings)
Join Date: Dec 2007
Location: On or near a dike
Posts: 9,836
|
Quote:
Originally Posted by Lawrence
Looking at the performance meter when doing those operations it seems that they only use one core.
|
2 cores here as you can see and the "All the things you are.mid" file from your zip file takes ~20s to explode in the various modes. The funny thing is that splitting the .mid on import is instantaneous and doing it afterwards takes those 20s.
|
|
|
07-21-2009, 08:57 PM
|
#15
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
Quote:
Originally Posted by Jason Brian Merrill
confirmed.
|
Thanks. Hopefully the devs will focus on a method for directly addressing and/or extracting and/or modifying note, pitch, controllers, etc, etc in a random way very fast from the timeline and rewrite the code accordingly. I don't see any way code that slow could sustain the kind of advanced midi editing functions that most pro sequencers have - that go way beyond splitting by pitch or channel - without annoying users ... *if* that's part of the master plan.
It actually may not be in which case it's all moot.
|
|
|
07-21-2009, 08:58 PM
|
#16
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,821
|
Fixed for 3.07.
|
|
|
07-21-2009, 08:58 PM
|
#17
|
Human being with feelings
Join Date: Jun 2006
Posts: 22,572
|
Quote:
Originally Posted by Lawrence
Thanks. Hopefully the devs will focus on a method for directly addressing and/or extracting and/or modifying note, pitch, controllers, etc, etc in a random way very fast from the timeline and rewrite the code accordingly. I don't see any way code that slow could sustain the kind of advanced midi editing functions that most pro sequencers have - that go way beyond splitting by pitch or channel - without pissing people off ... *if* that's part of the master plan.
It actually may not be in which case it's all moot.
|
something tells me this bug or bad code or whatever it is has a very short lifespan...
|
|
|
07-21-2009, 08:59 PM
|
#18
|
Human being with feelings
Join Date: Jun 2006
Posts: 22,572
|
Quote:
Originally Posted by schwa
Fixed for 3.07.
|
haha, i knew it.
|
|
|
07-21-2009, 09:00 PM
|
#19
|
Human being with feelings
Join Date: Jun 2007
Posts: 204
|
Yeah, didn’t think this one could hide under the developers’ bed for very long.
|
|
|
07-21-2009, 09:08 PM
|
#20
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
Quote:
Originally Posted by schwa
Fixed for 3.07.
|
Well hot damn.
Feel free to put "Fixed for 3.07" in the title of this thread.
I didn't report it as a "bug" since I didn't think it was a bug. I thought it was just a slow code block, not a bug. I mean... progress bars have to be placed intentionally in applications at certain places so it was quite clear to someone from the start that this routine would take some time, which is why a progress bar was placed there to let the user know it was still working? Things that happen in 1-2 seconds don't need progress bars, they use the windows "busy" mouse cursor.
Progress bars are (in some cases like these) for big looping code routines that take time.
Either way... I'm glad it will be fixed soon.
Last edited by Lawrence; 07-21-2009 at 09:20 PM.
|
|
|
07-21-2009, 10:52 PM
|
#21
|
Human being with feelings
Join Date: Aug 2008
Location: dusty hot place
Posts: 1,492
|
Quote:
Originally Posted by schwa
Fixed for 3.07.
|
That was fast
__________________
... yOu aNd mE are ...
|
|
|
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 07:53 PM.
|