Closed jonjamcam closed 8 years ago
Jon, in your first item ("bug" triggered immediately when I added a subchannel to the kontakt channel) are you using a kontakt library and loading samples from hard disk, right? If yes I will try reproduce the problem here. My idea is 1 - create a channel and load a big kontakt library. 2 - Create a subchannel and check if the midi messages are ok.
Yes. In other words. I jammed about 2 hours using the Abbey Road library (modified to load in sample mode) with no problems. Then I needed to add an audio track, so I added a subchannel. 1 minute later, the "bug" appeared (high latency in the midi). I had to restart Jamtaba.
Then (because of the bug) I used 2 channels (1 for kontakt and 1 for audio) and there were no problems.
Ok did the simple test you asked:
1 - Open Jamtaba. Open midi preferences and selected all your midi devices. 2 - Close Jamtaba. We need a clean log for the next Jamtaba session. 3 - Reopen Jamtaba. This will generate the initialization log, including the midi log. 4 - Close Jamtaba. 5 - Check the new log file. The midi initialization is still duplicated for your devices?
Answer (looks it's not duplicated):
So in your opinion the duplicate initialization can mess things up?
MY latest tests with Abbey Road Drums library show no problems (during several jams), but I did one test with the Kingpin set and I had the bug again. It looks there's something wrong with Analogue Drums sets specifically (both I've tried). Maybe the kontakt script has a bug?
Jon, your log file is ok, no duplicated midi initialization. Maybe the Kontakt script is the problem, this is possible. You experienced the same problem using Reaper or is a Jamtaba only problem?
I will test this bug in my kontakt soon, but I don't have the Kingpin lib. I will test using a huge piano library.
It only happens with Jamtaba. I'll keep testing and comparing.....
//removed
@jonjamcam , I got your link in my email (the github notifications). The file is downloaded here (~700 MB), I will test soon.
^^^^ GOOD! didn't want to do something wrong.
EDIT: this is a compressed version of the lib. I have not tested it with Jamtaba yet, but it will be the one I use from now on. I chose this approach because kontakt compression uses half memory than WAV.
@jonjamcam , I tested the KingPin lib but can't reproduce the bug. But I changed the midi code to take some precautions. See the PR #324.
OK. I will connect this week and start testing again as much as I can. I have another hypothesis about what could be the problem (not tested yet):
This lib ( as all analogue drums libs) comes with WAV files originally and this is how I've always used it, but testing other libs I noticed they use the NCW and there's no bug in those cases.
The bug only appears with analogue drums libs (kingpin and smoker tested). Never had a problem with Abbey Road Modern Drums for example.
So I converted the kingpin lib to ncw and this is the one I'll be using from now on (the same you have). Another reason to do this file conversion is the size in memory went down from 1.22 GB to 700 MB!
So anyway I'll stick with this one and I hope I don't meet the nasty bug :D.
1st test. passed. :+1:
no bug
two channels: 1st kontakt-kingpin(ncw compressed), 2nd line in
Nice news!
Test 2 passed. I'm playing like a horse to test it! If the bug was there It would have triggered already.
1 more test: use subchannel with a line input. what happened to me here https://github.com/elieserdejesus/JamTaba/issues/209#issuecomment-204613699
I have a suspicion that audio subchannels in a midi track can lead to trouble. If I'm proven correct, then the subchannel will have to be chosen from the same type of track (midi-midi or audio-audio). But this is only an hypothesis.
Ok tested the midi-audio channel-subchannel configuration and it's ok. no more bug. Closing.
andd too much happiness and it just happened. Same happened as in https://github.com/elieserdejesus/JamTaba/issues/209#issuecomment-204613699 but using kingpin. I think there's a problem when combined sub and channel are from different type.
Anyway when using kontakt olny in one channel I have no more bug.
So next test will be kontakt and a midi subchannel. The expected result is have no problems.
Ok Jon, let's keep the issue opened but assigned to the 2.0.15 version.
Tested. No bug. Details:
CH1:sub1:kontakt kingpin CH1sub2:piano (philarmonik)
CH2: Line in with VST fx (gate)
I think the hypothesis is proving true so far. Midi chaannel with Audio subchannel leads to some kind of mess in MIDI data. I will keep this configuration all next week to test.
@jonjamcam , I tested Kingpin in first subchannel and a second audio subchannel. No bugs, but I tested just for some minutes. In your reports the bug appears after some time jamming, right?
We need further testing then. I will test next week all I can (hopefully every afternoon).. This is what happens in my own systtem and I use it to the extreme.
In your reports the bug appears after some time jamming, right?
Yes.in average after 20-30 mins of uninterrupted playing, but sometimes after 1 or two hours.
@jonjamcam , if possible try check Jamtaba memory usage when start the jam (after load your plugins), and if the bug appears please check the memory usage again. Maybe we can have some problem in memory usage and this problem is accumulating, but it's just an idea at moment.
Happened again, so nothing to do with the midi-midi audio-audio subchannel hypo. We discard that.
Snapshot:
I stil have it open with the bug happening, so we can do further testing...What I did was to record (with midi) a drum loop and then start to use the audio track (CH2). the subchannel has a midi piano that is not altered. Only the kontakt subchannel. I was compiling, so I have open QT creator too.
EDIT: It really looks like I'm out of memory, so you may be right.
Qt creator shows this:
(I was testing the "transmitting" translations).
EDIT: @elieserdejesus I'm going to focus on testing extreme memory conditions next. I think you are on the right track
@jonjamcam , I see your memory usage was 86%. In general windows will use virtual memory in these conditions and you will have a very bad experience in overrall performance. But I remember you mention something about turning off the virtual memory in your windows. Are you using virtual memory or turning off?
Are you using virtual memory or turning off?
I do not use virtual memory. Never used it with this laptop. I need it fast to be able to use the lowest latency possible.
@jonjamcam , the print you posted (with 86% or memory usage) is after or before the bug appear?
it was taken a bit after.
@jonjamcam , I experienced the bug for the first time. I was playing (using kontakt) and after some time the bug appear. Huge latency, random midi notes, exactly like in your video. I try remove kontakt, switch the track input to "no input" and change to midi again, no result. Still buggy, latency, etc.
I was playing a lot of notes in piano, using two hands and playng with sustain pedal. When the bug starts I tested play just the same note. Every time I play the same note a random note was played. After some seconds I understand the problem: the midi messages are "queued" by rtMidi but not consumed by Jamtaba.
To test my hipothesys I just open the preferences dialog (to force audio and midi drivers stop) and close (to restart audio and midi). The bug disappear when audio and midi are restarted. So I"m shure is something in RtMidi or in Jamtaba RtMidi usage.
I will try test a huge ammount of midi messages to see if the problem appears. I think I have a good clue.
Any ideas why RtMidi behaves like this? We know the trigger could be many things (low memory, slow HDD. etc.).
@jonjamcam , I check RtMidi repository and no issues related with this problem. I checked the Jamtaba code and removed a log line in the piece of code handling the midi messages. It's not a good place to put a log line (too many messages if the log is activated). This log entry is my first suspect at moment. I'm not shure if the log is completelly bypassed when the log category (jtMidi) is disabled in logging.ini.
I think the problem is not low memory or HDD, I don't have these problems and the bug appears here too.
Next time you experience the bug just try open preferences panel and close. This will reset the midi driver and I'm almost shure the bug will disappear. If my hypo is correct we can discard the low memory problem.
Ok. I start tomorrow with another round of tests.
I'm testing the last version compiled today.
1st test. no problems using subchannel with audio input and another channel with midi vst instrument.
2nd test: kontakt + nexus + line in. All playing simultaneously on ninbot 2052 (5 users). Not one problem :D (this was the most likely case to fail. I'm using a win7 >4 years old laptop)
Tested again with other konakt libs and no more bug. I think it's solved. Waiting for your tests @elieserdejesus to close.
@jonjamcam , my last tests are ok.
great! let's close it for good!
Hi Elieser. I just did some testing of this bug and I'm not experiencing it with reaper(reaninjam). Only with Jamtaba (standalone) (tested versions 2.0.9, 2.0.6 and 2.0.5) 32bit and 64bit. (not tested jamtaba vst yet)
It happens randomly when using Kontakt and KingPin Drums: All the midi sent by my SPD-30 gets scrambled. This means that I play the Bass drum and it triggers the snare or if I press the hihat pedal and the kick drums is triggered. Additionally latency goes significantly up. Sometimes it sounds like the notes are "jammed" and when one pad is played many are triggered like a cascade..
It happens sometimes just as I enter a ninjam Room, other times when I'm in the middle of the jam.
Closing and reopening kontakt doesn't solve the issue nor changing ninjam rooms. It is solved only by closing Jamtaba and reopening.
I'm using Kontakt 5.5.0 now, but I tested 5.4.3, 5.5.1 and the problem persists.
Cheers!