Replies created

 

Viewing 15 replies - 1 through 15 (of 15 total)
  • Kari Smolander
    Participant

    Yes, exactly. I am adding them only through Play style.

    Kari Smolander
    Participant

    Thanks for your help! I have tried both, create the hits to an existing future hit in the superior set in my studio one template , and create a new future hit tambourine. In both cases there is no alignment / or there is a shuffle/swing in tambourine when faster than 4th. In both cases I am using the future hit square top left in style edit and the knob to add hits.

    Kari Smolander
    Participant

    I choose the block, go to play styles, select the future hit (tambourine) and then rotate the knob to 8th Acc 1 2 3 4

    This is an imported drum midi, but I have edited it extensively and split it to about 8 bar blocks which I edit one at a time.

    K.

    Kari Smolander
    Participant

    I seem to have had a similar kind of problem already three years ago. I did not receive any help at that time. Is Toontrack aware of this problem? https://www.toontrack.com/forums/topic/after-3-2-0-update-all-my-tambourines-are-suddenly-late-a-lot/

    Kari Smolander
    Participant

    Yes, I could do that or I could use Skaka. However, I would like to understand why SD3 is doing it wrong.

    Kari Smolander
    Participant

    Any progress on this issue? I contacted support a week ago and have received no answer.

    Kari Smolander
    Participant

    I have almost the same issue. My song, save file and kit does not open, because 3.2.0 crashes at load. It does not matter if I open it standalone or with Studio One. I have sent the files to support, but no answer or any kind of reaction. Now my project is totally stuck. It seems that downgrading to 3.1.7 would require downloading of about 50 gigabytes of samples. 3.2.0 sound set is not compatible to 3.1.7. Should I really do this download?

    I have included the problem kit.


    Reply To: SD3 Opens But Kits Won't Load version: 3.2.0
    Operating system: Windows 10
    Kari Smolander
    Participant

    @Henrik said:
    Can you upload a Superior Drummer 3 saved project file, that has these problems, so the coders can have a look at its behaviour? We haven’t gotten this bug report before, so it would be helpful!  

    sd3p files are not allowed. I changed the extension to jpg. Please download and change back to sd3p. Opening it in Superior will take about 15 minutes or so.
    Sorry – Upload file size exceeds maximum allowed size
    Here it is: https://www.dropbox.com/s/lhhzk5q64xwtvw3/x13s3-3.sd3p?dl=0

    @Patrik said:
    What version of Superior Drummer 3 are you running?
    I know we have had a bug previously where moving MIDI events (specifically CC/AT) would create duplicates in some situations, leading to a massive increase in the number of events, eventually leading to slow downs like the ones you describe here.  

    Superior version 3.1.1. This must be the same bug.

    Kari Smolander
    Participant

    I deleted all generated CC4 events and now everything works fine again. My summary is that there is a bug in Superior 3 that appears with controllers in block borders. In certain situations Superior may generate huge numbers of controller events. I may be wrong, because I do not know the internals of Superior 3, but that is my interpretation of the problem and how I solved it.

    Kari Smolander
    Participant

    I think I found the reason for the problem – or at least an important symptom. I inspected the midi file that I exported from Superior. The Grid Editor had inserted a huge number of CC4 events in one position, in measure 20:01:000. They were not in the original MIDI from the edrum. I do not know why and how this happens, but this should be corrected. There is a block border in 20:01:000, so this may be related to a bug in block processing.

    Kari Smolander
    Participant

    Yet another observation. When I open the same drum project with Superior standalone, it also takes forever to load.
    The original MIDI was 67 KB, the MIDI exported from Superior was 785 KB and the Superior project file size is 11034 KB.
    Something in Superior add complexity to the MIDI. I have mostly only removed shadow hits caused by the edrum and moved hits between cymbals. And of course some slight quantization.

    Kari Smolander
    Participant

    I deleted all CC4 events from the song. I selected all, which took about 5 minutes processing time and then pressed delete. After about 30 minutes they were deleted.
    It did not help. An event move in grid editor still takes minutes.

    Kari Smolander
    Participant

    The problem could be related to CC4. Somehow the grid editor cannot optimize them but causes some kind of exponential growth of interrupts. When I open the CC4 view instead of velocity in grid editor, Superior gets stuck.
    EDIT: Superior version 3.1.1

    Kari Smolander
    Participant

    When I load the saved Superior 3 project to a new song, the problem persists. Each event move takes minutes. This means that the corrupted or inefficient data structure is stored in the project file and not optimized when opened to the new song.

    Kari Smolander
    Participant

    It seems that the Superior 3 project gets somehow corrupted or the data structure becomes too complex and inefficient. The performance problem stays even if I save the Superior project and open it in a new song. Importing the S3 song takes several minutes and the song is a quite normal 4 minute pop song with three toms, three cymbals and most hits are in 1/8 positions. The only complex thing is the hi hat CC4 controller, which does not have too many events either. This performance problem makes now using S3 impossible, because all event changes take several minutes. The project has one TH3 plugin, one Fat Channel and one Room Reverb. It is in its initial phase with only three recorded tracks and the drum midi. It takes only about 10% of processor capacity.

Viewing 15 replies - 1 through 15 (of 15 total)

No products in the cart.

×