MIDI GUITAR 3 for Windows

BETA TESTING
81

Instead of Roland’s asio driver, you should try ASIO4ALL, which allows you to select 128s ou 256s.
https://asio4all.org/

82

trying that now, will report

83

Genius! Works perfectly, Asio4All changes the buffer, and I have good tracking (as good as possible with old sound card) Thanks so much for troubleshooting with me!

1 Like
84

Don’t worry, we’re all here to help each other, and it’s always nice to hear that a problem has been solved. :slightly_smiling_face:

1 Like
85

Firewire was for a long time the best performing connection (and still performing today), but its gradual abandonment due to the progress of USB is now forcing us to switch to USB audio interfaces in order to remain compatible with today’s computers and peripherals at a lower cost.
What’s more, there are now many high-performance audio interfaces available at a reasonable price.

1 Like
86

i haven’t tried this yet, but last night i realized that using two audio interfaces could provide a significant reduction in latency for those who are running their vsti’s in a daw.

interface1 would be set to the lowest acceptable sample rate and interface2 would be set at 256 or even higher if the user’s combo of instruments or effects require it.

midiguitar runs standalone on interface1, the midi gets sent to the daw on interface2.

interface1 could be an inexpensive single input device.

if i’m right, this would be a best of both worlds situation, in terms of lowest possible latency while retaining the ability to run heaps of vst’s.

if one still needs the mg3 chains and devices and efx for certain songs/instruments, then sharing the guitar output between interface1 and 2 will provide that option, although with the higher sample rate.

87

@Progster, I was thinking about this and I finally start to get some ideas.

The distinctions between “global” vs “patch-level” vs “configuration-files” seem wrong to me. How about the following:

  1. There is no global data or configuration files data.
  2. Each patch exists as a file in a folder, and it can save all settings. So, patches exist in a file hierarchy/subfolder structure.
  3. In any subfolder you can have a “Default” patch, which all patches in that subfolder inherit from.

So for example, consider this file hierarchy:

/Patches/Default.patch
/Patches/MIDIGuitar/Default.patch
/Patches/MIDIGuitar/FCB1010/Default.patch
/Patches/MIDIGuitar/FCB1010/SomePedalBoardPatch1.patch
/Patches/MIDIGuitar/FCB1010/SomePedalBoardPatch2.patch
/Patches/MIDIGuitar/BreathControl/Default.patch
/Patches/MIDIGuitar/BreathControl/Sax1.patch
/Patches/MIDIGuitar/BreathControl/Sax2.patch
/Patches/MIDIBass/Default.patch
/Patches/MIDIBass/MonoSynths/Juno.patch
/Patches/MIDIBass/MonoSynths/Brute.patch

So you can construct a hierarchy of patches (in subfolders) and each level will add settings on top of the Default ones.

In my example, all patches will inherit the settings of /Patches/Default.patch, and then any other Default in its path.

At the extreme:
Sax1.patch will load the settings of /Patches/Default.patch, then add the settings of /Patches/MIDIGuitar/Default.patch and then add the settings of /Patches/MIDIGuitar/BreathControl/Default.patch and finally add the settings of /Patches/MIDIGuitar/BreathControl/Sax1.patch

For this to work, MG3 will automatically do the lifting for you when saving a patch: It will automatically lookup the folder structure and find and add up any parent default patches. If the settings you are saving is already saved in this default patch, the settings are not saved in the patch. Any setting that differ from the defaults will be stored in the patch.

Loading is simple: MG3 will just add up the folder hierarchy of defaults and then finally the settings stored in the patch.

At any time can you load a default patch and change it. That will affect all patches in its folder and subfolders.

Any everyone who dont care about all this, will not notice, as they dont have any default patches.

1 Like
88

Hi @JamO.

Very interesting approach, thanks for posting it.

A couple of questions come to mind initially:

  1. Are the .patch files text files which can be edited? Or would all changes have to be made and saved via the program itself?

  2. Do I understand that a Default.patch could be any of: a) some defined CCs, some blanks, all unconnected to anything b) some defined CCs connected to some specific things, along with some blanks c) the full set of CCs, unconnected to anything, d) the full set of CCs, all connected to something ?

  3. The user, creating a new patch, would get an empty one, and if that is not desired then the correct action would be to load one of the existing (if any) Default.patch files instead from someplace in the hierarchy ?

Under this scheme, would MG3 be supplied with an initial hierarchy of some meaningful effect that would demonstrate the scheme?

It’s a very interesting idea and I will try to think more about it. Thanks again!

1 Like