Old 07-21-2009, 06:04 PM   #1
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default 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.
Lawrence is offline   Reply With Quote
Old 07-21-2009, 06:34 PM   #2
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

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.
Lawrence is offline   Reply With Quote
Old 07-21-2009, 07:21 PM   #3
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

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.
Lawrence is offline   Reply With Quote
Old 07-21-2009, 07:24 PM   #4
Jae.Thomas
Human being with feelings
 
Join Date: Jun 2006
Posts: 22,567
Default

excellent observations.

can anyone else repro?
Jae.Thomas is offline   Reply With Quote
Old 07-21-2009, 08:04 PM   #5
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,480
Default

Quote:
Originally Posted by Lawrence View Post
This is insane. It's only 37kb of midi data total.
Why don't you just upload such midi file?
Dstruct is offline   Reply With Quote
Old 07-21-2009, 08:20 PM   #6
dub3000
Human being with feelings
 
dub3000's Avatar
 
Join Date: Mar 2008
Location: Sydney, Australia
Posts: 3,955
Default

Quote:
Originally Posted by Lawrence View Post
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.
dub3000 is offline   Reply With Quote
Old 07-21-2009, 08:24 PM   #7
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Quote:
Originally Posted by Dstruct View Post
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.
Lawrence is offline   Reply With Quote
Old 07-21-2009, 08:26 PM   #8
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,480
Default

Ok, confirmed. Slow


FIXED (3.07pre4)


http://forum.cockos.com/project.php?issueid=664

Last edited by Dstruct; 08-03-2009 at 03:18 AM.
Dstruct is offline   Reply With Quote
Old 07-21-2009, 08:29 PM   #9
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Quote:
Originally Posted by dub3000 View Post
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.
Lawrence is offline   Reply With Quote
Old 07-21-2009, 08:43 PM   #10
beatbybit
Human being with feelings
 
beatbybit's Avatar
 
Join Date: Jul 2006
Location: Hungary
Posts: 3,129
Default

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
beatbybit is offline   Reply With Quote
Old 07-21-2009, 08:46 PM   #11
Julio
Human being with feelings
 
Julio's Avatar
 
Join Date: Jun 2007
Posts: 204
Default

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.
Julio is offline   Reply With Quote
Old 07-21-2009, 08:47 PM   #12
Jae.Thomas
Human being with feelings
 
Join Date: Jun 2006
Posts: 22,567
Default

confirmed.
Jae.Thomas is offline   Reply With Quote
Old 07-21-2009, 08:47 PM   #13
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Quote:
Originally Posted by beatbybit View Post
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.
Lawrence is offline   Reply With Quote
Old 07-21-2009, 08:51 PM   #14
Ollie
Super Moderator (no feelings)
 
Ollie's Avatar
 
Join Date: Dec 2007
Location: On or near a dike
Posts: 9,834
Default

Quote:
Originally Posted by Lawrence View Post
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.
Ollie is offline   Reply With Quote
Old 07-21-2009, 08:57 PM   #15
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Quote:
Originally Posted by Jason Brian Merrill View Post
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.
Lawrence is offline   Reply With Quote
Old 07-21-2009, 08:58 PM   #16
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,750
Default

Fixed for 3.07.
schwa is offline   Reply With Quote
Old 07-21-2009, 08:58 PM   #17
Jae.Thomas
Human being with feelings
 
Join Date: Jun 2006
Posts: 22,567
Default

Quote:
Originally Posted by Lawrence View Post
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...
Jae.Thomas is offline   Reply With Quote
Old 07-21-2009, 08:59 PM   #18
Jae.Thomas
Human being with feelings
 
Join Date: Jun 2006
Posts: 22,567
Default

Quote:
Originally Posted by schwa View Post
Fixed for 3.07.
haha, i knew it.
Jae.Thomas is offline   Reply With Quote
Old 07-21-2009, 09:00 PM   #19
Julio
Human being with feelings
 
Julio's Avatar
 
Join Date: Jun 2007
Posts: 204
Default

Yeah, didn’t think this one could hide under the developers’ bed for very long.
Julio is offline   Reply With Quote
Old 07-21-2009, 09:08 PM   #20
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,551
Default

Quote:
Originally Posted by schwa View Post
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.
Lawrence is offline   Reply With Quote
Old 07-21-2009, 10:52 PM   #21
SiKo
Human being with feelings
 
SiKo's Avatar
 
Join Date: Aug 2008
Location: dusty hot place
Posts: 1,492
Default

Quote:
Originally Posted by schwa View Post
Fixed for 3.07.
That was fast
__________________
... yOu aNd mE are ...
SiKo is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 02:55 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.