Here is a refined version of the workaround. It is an attempt to solve problems where sequencer playback does not work properly. It applies mainly to Logic Audio being run on the same machine as GigaStudio, but could be (and has been) made to work for similar problems for Powertracks, Cakewalk 9, etc. I have tried to document all of this here.
In addition, it may turn out to cure all sorts of misc MIDI problems.
I decided to post this refinement as a new thread, rather than confusing the issue by making edits to the previous threads. I also hope that this time around I can explain why some of you have not been able to make it work, and what you could hopefully do to solve the problem.
PLEASE read my final note right at the end - this will help me better help you (as the saying goes...)
The workaround still uses Hubi. The differences from the original workaround are listed at the end. The main difference is that you no longer have to start up any Midi cables (hwmdcabl.exe)
The refined workaround consists of 3 installation steps. In summary (detail follows below), these are:
1) Obtain and install Hubi\'s loopback driver. This adds 4 Midi ports to your system: LB1-LB4. Can be used as inputs and outputs.
2) Ensure that your sequencer does not open LB1-LB4 as inputs. In Cakewalk this can be set from the Midi device setup menu, for Logic the win.ini file must be edited. Powertracks info appears in the detail description later on. (What will happen if you do not take this step, is that you may experience \"feedback\" problems, your sequencer may refuse to start playback/recording (i.e. stuck song position) or you may experience freezes and lockups when starting or stopping sequencer playback/recording).
3) Set the MIDI input ports in GigaStudio to LB1, LB2, LB3, LB4. Click on \"Apply,\" otherwise GSt does not remember the settings! *Note: Contrary to what a few people have suggested, this was never part of the original workaround - both approaches have advantages and disadvantages: more detail later.
And that is it. Simply have your sequencer route data to LB1-LB4 instead of to Nemesys Midi port 1, etc.
Everything now hinges around the following:
(a) Within your seqeuncer, for each track / instrument where you had previously selected \"Nemesys Midiout Port 1\", now select \"LB1\" (for Nemesys port 2, select LB2, etc. etc.)
(b) In future when you start GigaStudio, note the little keyboard icon on the left of your screen in the middle (just above the 1 - 4 midi ports icons). When GSt is started \"fresh,\" this icon is white.
NOW: AS SOON AS you start your sequencer (from the little notes-icon), that keyboard icon will turn RED or start flashing RED. You do NOT want this (it means that GSt is now listening on Nemesys ports 1 - 4 instead of on LB1-4, as set in the GSt midi setup).
THEREFORE, click on the keyboard icon so that it turns WHITE again. When midi data is transmitted from the sequencer, the appropriate midi icon should light up in GSt.
This may have to be done every time you start the sequencer.
The drawback to this method is that you can no longer audition instruments without first starting your sequencer - this also applies to editing samples. You will only be able to play GSt by playing it \"thru\" your sequencer (i.e. select the appropriate track in the sequencer and play your instrument). This is pretty much the standard way of working, so should not present a problem for most people. However, if you miss this functionality, there is a way around it - more detail later.
(Note: when starting the editor on a sample, you may get a message saying \"Unable to open Nemesys Port\" - this does not seem to be any problem, however).
And now, on to the detail of the various steps: 1) Obtain and install Hubi\'s loopback driver
Hubi provides the following: 4 ports (LB1 - LB4) which are multiclient ports, both input and output. Anything sent to LB1 as an output port, will appear on LB1 as an input port.
Install Hubi - the default settings are fine.
2) Configure your sequencer
Select the instructions particular to your sequencer:
Cakewalk: Can\'t exactly remember, but open the Midi device setup dialog in Cakewalk, and make sure that LB1-LB4 are not highlighted in the \"Inputs\" column.
Powertracks: Here is a comment posted by jb3. Try this. I am awaiting official comment from PG tech support; I will add it here as necessary.
\"Within the PowerTracks Pro Audio (PTPA), Select your normal external H/W midi interfaces as usual. For example, I have a Midiman Portman 4X4/S parallel port midi interface. My yamaha PSR is in on IN/OUT 2, and my drum machine is on IN/OUT 1. These I select as the input drivers for PTPA\'s Midi Driver Setup. For PTPA\'s Output Drivers, DO NOT select the nemesys midi out ports. Select LB1,LB2,LB3,LB4, and your H/W midi I/F outputs only.
Logic: Start Logic, and then close it again. This is so that Logic can discover the newly-installed ports. (Thanks to Freud for reminding me of that!)
Now, open win.ini (easiest is to click on Start -> Run and execute \"sysedit\", then edit the win.ini window)
Look for the section
In this section, look for the 4 lines
For these 4 lines, change the 1 to a 0, i.e.
This will tell Logic *not* to open these ports as inputs, so Logic will open them only as outputs. Logic will now be able to record / playback as normal.
(* NOTE: Be VERY carefull NOT to edit the MidiOut_LB1 to LB4 lines. This will entirely defeat the object of the excercise All the MidiOut_LB lines should STAY = 1)
For added stability, I would also recommend setting the 1\'s to 0\'s on the Nemesys ports, i.e.:
This will cause the Nemesys Ports to no longer appear within Logic, which also means that Logic will not send any reset / start-stop data to them. I get the distinct impression (though I may be wrong) that this leads to fewer crashes.
In addition, if you are using Emagic SoundDiver, it would probably be a good idea to make the same changes to the [sounddiver] section in win.ini
Just remember that when a fix finally appears, these settings will have to be returned to their original value. I would recommend noting down your changes, rather than making a backup copy of win.ini - because by the time the fix appears, your win.ini file would probably have been changed by other programs, and you don\'t want to restore an old copy over those changes.
After making changes to win.ini, it is wise to reboot. Not always necessary, but I\'m paranoid.
3) Configure GSt
Start GSt. Go to Settings. Select the Hardware/Routing tab (if you do not see it, drag around the separator between the settings-panel and the quicksound database - I have found that it can sometimes get obscured.)
In the left column (Midi In to Midi Out Mapping), select
(i.e. one for each input port in GSt)
CLICK ON \"APPLY\" (otherwise GSt will conveniently forget the changes)
And that is it.
Remember to click on the little GSt keyboard icon if necessary, so that it turns white, AFTER starting the sequencer. Otherwise you will hear nothing.
Comment on processing power:
For those of you who worry that use of Hubi may put extra pressure on your machine and decrease your polyphony, the following reassurance: Hubi seems to be a very high performance piece of code. It requires virtually no overhead, and should in no way interfere with anything.
As a matter of fact, as far as I can tell, Giga\'s built in ports (Nemesys Port 1, etc.) do pretty much the same thing as LB1, LB2, etc., in the sense that they also seem to be loopback drivers! Using Hubi, you are thus basically exchanging one set of loopback drivers for another - this should not use up additional processing power.
Differences between this refinement and previous workaround:
The original workaround was different, in the sense that I used Hubi\'s hwmdcabl.exe to \"connect\" LB1 to Nemesys Port 1, LB2 to Nemesys Port 2, etc.
This allowed one to use the system *without* having to click on the little keyboard icon.
Contrary to what many people have suggested, in that configuration it was *not* necessary to set the input ports inside GSt to LB1-LB4: they could stay the way they were. In my system, port 1 input was set to SW1000 Input (for my external keyboard), with all others being set to none.
This allowed me to audition parts on port 1, without having to start the sequencer.
This new refinement now sets the GSt input ports to LB1 - LB4. The advantage one gains is not having to start hubi midi cables. The disadvantage is losing sequencerless auditioning from external keyboard.
The solution: if you want to do sequencerless auditioning, start GSt FIRST, then simply start an instance of Hubi\'s Hardware Midi Cable (hwmdcable.exe - included with the loopback driver). Right-click on it in your task bar, then select your input port (i.e. in my case SW1000 MIDI IN) in the middle column, and the appropriate LB port in the output column (LB1 for port 1, etc.) Remember to make sure that the keyboard-icon in GSt is WHITE only.
You can even start more instances of hwmdcabl, if you would like to \"connect\" other external Midi ports to LB2, etc.
BE WARNED however, that if inspiration suddenly strikes and you want to start up your sequencer, you have to close all those cables BEFORE starting the sequencer (just right-click on all the cables in the task-bar and select \"close\"). Otherwise, your sequencer probably won\'t be able to open those external input ports (\'cause they are normally single-client ports which have already been opened by hwmdcabl)...
BTW: if you did not understand what I was trying to achieve in this section, it is not important for your purposes in any case, so it does not matter
Hubi is handy for many things. It can help you fix timing trouble, where events seem to be recorded ok, but play back all jittery (or the other way around). Some Gravis Ultrasound cards had this problem.
It also allows you to access Midi ports from more than one program simultaneously. E.g., you can have your sequencer open, as well as an editor program for a synth. No more dreaded \"Device already in use\" problems.
I would like to add that I personally suspect the Midi problem we are all experiencing is not specifically a Logic or GSt problem. I think it is some interaction with timing code inside Windows. That would explain why some people suffer and others don\'t (and why loading audio clips into the audio import window in Logic may or may not influence the problem...)
I must admit that I get a bit frustrated when people post with \"Couldn\'t get it to work.\" Ok, this is just a workaround, but it seems to have good success, and chances are that between my explanation and your set-up, we might just be missing a tiny detail.
Please please please give me some observations (i.e. when you tried playback, what happened, or failed to happen? Can you play \"thru\" the track? etc.) Just saying \"couldn\'t make it work\" leaves me utterly in the dark, whereas otherwise I may still be able to help you. Thanks.
Thanks to the people so far who have provided feedback - in the absence of a fix, I would like to get a workaround out that is as solid as possible
Regards to all,
[This message has been edited by cc (edited 07-07-2000).]
I have historically used the public domain Midiloopback driver (part of the Midi-OX product) with similar success to Hubi. I will test the above using Midiloopback and see if there are any differences or advantages.
That would be good. Midi-Ox is quite a nifty tool. I wanted to test out Midi Yoke, but I have not been able to download it - the link is not connected from the Midi-Ox page. Heheh, well, at least not when I checked...
At this stage, the only difference I know of is that Midi Yoke works under NT/2000, whereas Hubi does not. But this is not relevant (yet), \'cause GSt doesn\'t either...
What may be handy is running Hubi & Yoke together? Hubi only gives 4 ports, which is enough for GSt, but not if you want to sort out other Midi problems as well.
Hahaha, that would be something Well maybe something beneficial will come from it. In all honesty though, I cannot really test major configurations, since I simply cannot afford the gear. Its expensive everywhere, but especially so in Cape Town, where you can\'t even get to see most of the stuff in the shops.
Heh, thats where this whole troubleshooting thing started - in trying to set up a decent system on a limited budget...
At least if it cures some frustration, its usefull...
PS: Freud, I read in some other thread that you had problems with the workaround on 2 different machines? My natural curiosity makes me really wonder if you got it running eventually?
[This message has been edited by cc (edited 07-05-2000).]
\"Comment on processing power:
For those of you who worry that use of Hubi may put extra pressure on your machine and decrease your polyphony, the following reassurance: Hubi seems to be a very high performance piece of code. It requires virtually no overhead, and should in no way interfere with anything.\"
I have a graphic problem In Giga when I\'m monitoring on the Giga-GUI, it is displayed as super slow motion but monitoring on cakewalk without any problems (super fast).
Do you think the \"Hubi\'s loopback driver\" would helps or because it\'s normal?. Any ideas or suggestions?
Thanks in advances
Thanks for that! However I\'m baffled by one problem - latency. I can see why that shouldn\'t be a problem from your reasoning - makes sense. But with the new workaround, the latency problem increases significantly as compared with the old workaround. I\'m switching back to the old workaround at the moment and will try to experiment more later. However, I do like the idea of not having to start up hubi with this new workaround.
Do you have any ideas what\'s the problem? Maybe I\'m the only one experiencing this. But I\'m glad at least I can play back with Logic now.
Cheez, I\'m not sure what the cause of the increased latency could be. If others also experience it, please post: maybe my refinement is a dud...
Question for you: does the latency only increase when you start play/record, or do you have it while playing \"thru\" a logic track in stop mode as well?
If the problem is there even with thru in stop-mode, I think chances are you have a midi \"loop\" or \"short\" somewhere. Make sure that in [logic] in win.ini, the MidiOuts_LB are all = 1, and the MidiIn_LB are all = 0. Make sure you do not have hwmdcabl running to connect those ports to various other things. Also, if you use SoundDiver (?), it may influence your system.
I can think of a few other things that could be the reason:
a) that it is symptomatic of the deeper midi problem that is the source of all the drama. In this case it might be cured by step-by-step uninstalling and reinstalling of everything that uses / provides midi service (i.e. logic, hubi, gst, maybe even soundcard drivers)
b) that it happens because of buffer-size/allocation problems - I don\'t suppose you changed the [mdilpbk] section in system.ini by accident - still it shouldn\'t make much difference. Maybe something inside the routines which allocate system resources...
c) that it happens because GSt gives higher timing priority to input via its own loopback nemesys ports, than via its setup input ports. Not so likely, since this would make \"live\" playing (i.e. without sequencer) unresponsive.
d) that you experience a timing lag when logic is running (i.e. playback or record), because the system is unable to schedule everything to happen on time. Maybe indicative of a ram problem...
LHong, I don\'t think Hubi will make much difference to you. However, perhaps you should start by checking in Control Panel that your system is not sharing IRQs. This is especially true for your AGP card, IDE/SCSI interfaces and some soundcards.
I think shared IRQs may be likely in your system, \'cause the Athlon basically implies that you have an AMD75x chipset or VIA chipset. The latter is known to easily cause shared IRQs (in which case the solution I know is to move around your cards, especially the slots closest to and furthest from the AGP slot).
As an aside, I understand that the AMD75x chipset\'s PCI implementation has some known compatability issues with the Motorola DSP chip used on quite a few pro soundcards...
Also, just as a final check, its best to run win98se (or I suppose 98lite). Win98 has better scheduling than Win95, and apparently win95 does not have proper 32-bit timing capability, which is why its midi timing is so poor. This could also cause what you are seeing.