gleamsynth-devel Mailing List for Gleam
Status: Pre-Alpha
Brought to you by:
mlobo
Menu
▾
▴
gleamsynth-devel — Gleam development
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(18) |
May
(14) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
(17) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: jimmy <wg...@ya...> - 2009-02-22 19:28:01
|
Hi Miguel,
This should be slightly more efficient than what I had before.
Jimmy
>>>>>
GleamPreset* GleamSF2Library::getMidiPreset(int bank, int program, bool drumPreset)
{
if (drumPreset)
bank = DRUM_BANK;
int index = pr->sortedPresets.find(GleamSF2Preset::SortingKey(bank, program));
// If preset not found, try GM equivalent
if (-1 == index) {
if (DRUM_BANK == bank) {
// Try drumkit 0
index = pr->sortedPresets.find(GleamSF2Preset::SortingKey(DRUM_BANK, 0));
} else {
// Try bank 0, same program number
index = pr->sortedPresets.find(GleamSF2Preset::SortingKey(0, program));
}
// Preset still not found, try bank 0, program 0
if (-1 == index) {
index = pr->sortedPresets.find(GleamSF2Preset::SortingKey(0, program));
}
}
return index == -1 ? 0 : &pr->presets[index];
}
<<<<<
|
|
From: jimmy <wg...@ya...> - 2009-02-22 15:00:05
|
Hi Miguel,
Here's my change for GleamCore/src/sf2/sf2library.cpp to compensate for invalid midi program change requests. Let me know if I may have missed anything.
>>>>>
GleamPreset* GleamSF2Library::getMidiPreset(int bank, int program, bool drumPreset)
{
if (drumPreset)
bank = DRUM_BANK;
int index = pr->sortedPresets.find(GleamSF2Preset::SortingKey(bank, program));
// If preset not found, try GM equivalent
if (-1 == index) {
if (DRUM_BANK == bank) {
// Try drumkit 0
index = pr->sortedPresets.find(GleamSF2Preset::SortingKey(DRUM_BANK, 0));
} else {
// Try bank 0, same program number, which should be similar sound.
index = pr->sortedPresets.find(GleamSF2Preset::SortingKey(0, program));
}
}
// Preset still not found, try bank 0, program 0
if (-1 == index) {
index = pr->sortedPresets.find(GleamSF2Preset::SortingKey(0, program));
}
return index == -1 ? 0 : &pr->presets[index];
}
<<<<<
BTW, I also tried to declare
GleamSortedArrayIndex<GleamSF2Preset, GleamArray<GleamSF2Preset>, GleamSF2Preset::SortingKey> tmpPresets = pr->sortedPresets;
to try to use a local variable instead of doing object pointer calculation multiple times. It compiles, but core dumps. Any idea?
Jimmy
|
|
From: Miguel L. <ml...@gm...> - 2009-02-21 10:59:49
|
Hi Max, I'm going to go for a shameless plug here, because it seems my project might be of interest to you. The project is called Gleam (http://gleamsynth.sf.net), it's based on fluidsynth's code base and I started it precisely because of some of the limitations you describe. There is no real documentation (although the most important parts of the API are commented in the code), but there is a simple playmidi example that hopefully shows at least part of what you would need. Also, I would of course be happy to answer any questions you might have. > - there is no way to tell whether the "player" has finished playing a > MIDI file - the "status" attribute is not exposed. With Gleam you can add a "conditionsync" event at the end of the song (after loading it from a MIDI file or some other way) that signals a pthread condition variable when it is played. There is currently no way of checking for the end of the song synchronously, but I will add that (I didn't notice this feature was missing). > - the "player" insists on playing in real-time, all my attempts to > fill MPD's internal audio buffer as fast as possible failed, there > was only silence in the buffer after the fluid_synth_write_s16() > call. Gleam provides a readAudio() method that gives you however many samples you ask for synchronously and as fast as it can, and it advances the internal clock accordingly. The wall clock is not used at all. > - error handling in fluidsynth is awful. Most functions return an > undocumented "int", its meaning can only be derived from reading the > source, but I cannot grasp what's gone wrong, I cannot generate a > usable error message. Gleam might not do what you want here. Functions usually return a boolean ("true" meaning everything was OK, "false" meaning an error occurred), while warning and error messages are passed to a logger object. The default logger prints warnings and errors to the console, but you can replace this logger with your own one that can do whatever it wants with those messages. Maybe I should create some enums for the error codes so the calling application can easily distinguish between different errors. > - I don't want fluidsynth to create a new thread. Synthesize the MIDI > file synchronously in the thread which called the library. If you don't use Gleam's audio drivers (which it doesn't seem like you would), Gleam doesn't create or use any threads. Finally, if you do want to give my project a try, a word of caution: Gleam uses a non-standard build infrastructure, which has confused people in the past. It *should* be really simple to build the source for the 0.0.2 release, but building from SVN depends on some other software your Linux distribution might not ship. This is all described in the Documentation that can be found it the project's web page. Again, I'm more than happy to answer any queries. -- Miguel Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net |
|
From: jimmy <wg...@ya...> - 2009-02-20 13:17:52
|
Hi Miguel,
The " -d hw:1 " works now. Thanks.
The build warning was still there, but only for first build form SVN checkout. After that the build doesn't give that GCCXML warning. Here the current (subsequent) build output for me:
python build.py
build.py: Using compiler: g++
/usr/bin/ld: cannot find -lpython2.5
collect2: ld returned 1 exit status
build.py: Python binding support is not available.
build.py: ALSA support is enabled.
build.py: GleamCore (Shared, Library, Release) is up to date.
build.py: GleamCore (Static, Library, Release) is up to date.
build.py: GleamDrivers (Shared, Library, Release) is up to date.
build.py: GleamDrivers (Static, Library, Release) is up to date.
build.py: examples/common (Static, Library, Release) is up to date.
build.py: examples/playmidi (Shared, Application, Release) is up to date.
build.py: examples/synth (Shared, Application, Release) is up to date.
build.py: examples/dumpfile (Shared, Application, Release) is up to date.
Jimmy
|
|
From: jimmy <wg...@ya...> - 2009-02-20 00:04:10
|
--- On Thu, 2/19/09, Miguel Lobo <ml...@gm...> wrote:
> I'm surprised GCC-XML works for you with GCC 4.3. It
> doesn't for me
> (I've just checked) and I have the exact same gccxml
> package, although
> my gcc packages are the Ubuntu versions. That's why
> the documentation
> says to set GCCXML_COMPILER to g++-4.1 or g++-4.2.
I was thinking that was the case with the previous SVN build errors, too. But pygccxml-1.0.0 was the cause for me. Anway, I would be really reluctant to install another GCC just for this, plus my diskspace is running low for this machine right now to deal with that.
>
> > However, I have to set the LD_LIBRARY_PATH to be able
> to run the synth example. I didn't have to do this with
> gleamsynth-0.0.2.tgz.
> >
> > export
> LD_LIBRARY_PATH=./output/i486-linux-gnu/GleamDrivers:./output/i486-linux-gnu/GleamCore
>
> Yep, that is necessary, otherwise the dynamic linker
> won't find the
> libraries you've just built. It shouldn't be
> different with
> gleamsynth-0.0.2.tgz though. My guess would be that maybe
> you had the
> gleam deb package installed at the time, so you were
> running the
> executables you built against the libraries that were
> installed in
> /usr/lib? I've had that happen to me.
Nope, never installed the .deb. Never exported the LD_LIBRARY_PATH for gleamsynth until now.
> > The commandline parser didn't parse the -d option
> correctly. The "-d hw:1" didn't work.
>
> Sorry, yesterday I didn't have time to test that change
> properly.
> I've fixed it now, please try again.
Will try again when I get a chance.
Anyway, below is the outout from yesterday's SVN build, including the warning message just below the first
INFO GCCXML version - 0.9 BUGGY
Jimmy
-----
python build.py
build.py: Using compiler: g++
/usr/bin/ld: cannot find -lpython2.5
collect2: ld returned 1 exit status
build.py: Python binding support is not available.
build.py: ALSA support is enabled.
build.py: Analysing private headers for GleamCore ...
#include wrapper search starts here:
/usr/share/gccxml-0.9/GCC/4.3
#include "..." search starts here:
#include <...> search starts here:
output/common/GleamCore/copied-headers
/home/jn/tmp/compile/music.stuff/gleamsynth.svn.20090218/output/common/include
/home/jn/tmp/compile/music.stuff/gleamsynth.svn.20090218/output/common/GleamCore/private-headers
/usr/include/c++/4.3
/usr/include/c++/4.3/i486-linux-gnu
/usr/include/c++/4.3/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.3.2/include
/usr/lib/gcc/i486-linux-gnu/4.3.2/include-fixed
/usr/include
End of search list.
INFO GCCXML version - 0.9 BUGGY
/usr/lib/python2.5/site-packages/pygccxml/parser/scanner.py:337: UserWarning: unable to find out array size from expression ""
warnings.warn( msg )
build.py: Updating objects for GleamCore (Shared, Library, Release) ...
build.py: Linking GleamCore (Shared, Library, Release) ...
build.py: Updating objects for GleamCore (Static, Library, Release) ...
build.py: Linking GleamCore (Static, Library, Release) ...
build.py: Analysing private headers for GleamDrivers ...
ignoring duplicate directory "/home/jn/tmp/compile/music.stuff/gleamsynth.svn.20090218/output/common/include"
#include wrapper search starts here:
/usr/share/gccxml-0.9/GCC/4.3
#include "..." search starts here:
#include <...> search starts here:
output/common/GleamDrivers/copied-headers
/home/jn/tmp/compile/music.stuff/gleamsynth.svn.20090218/output/common/include
/home/jn/tmp/compile/music.stuff/gleamsynth.svn.20090218/output/common/GleamDrivers/private-headers
/home/jn/tmp/compile/music.stuff/gleamsynth.svn.20090218/output/common/GleamCore/private-headers
/usr/include/c++/4.3
/usr/include/c++/4.3/i486-linux-gnu
/usr/include/c++/4.3/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.3.2/include
/usr/lib/gcc/i486-linux-gnu/4.3.2/include-fixed
/usr/include
End of search list.
INFO GCCXML version - 0.9 BUGGY
build.py: Updating objects for GleamDrivers (Shared, Library, Release) ...
build.py: Linking GleamDrivers (Shared, Library, Release) ...
build.py: Updating objects for GleamDrivers (Static, Library, Release) ...
build.py: Linking GleamDrivers (Static, Library, Release) ...
build.py: Updating objects for examples/common (Static, Library, Release) ...
build.py: Linking examples/common (Static, Library, Release) ...
build.py: Updating objects for examples/playmidi (Shared, Application, Release) ...
build.py: Linking examples/playmidi (Shared, Application, Release) ...
build.py: Updating objects for examples/synth (Shared, Application, Release) ...
build.py: Linking examples/synth (Shared, Application, Release) ...
build.py: Updating objects for examples/dumpfile (Shared, Application, Release) ...
build.py: Linking examples/dumpfile (Shared, Application, Release) ...
|
|
From: Miguel L. <ml...@gm...> - 2009-02-19 23:30:05
|
Hi Jimmy, > The SVN build gave a warning, but did build OK. I don't have the latest packages from Debian Sid (Unstable), but here are the packages' versions from my "dpkg -l | grep gcc" command: > > ii gcc 4:4.3.1-1 The GNU C compiler > ii gcc-4.3 4.3.2-1 The GNU C compiler > ii gcc-4.3-base 4.3.2-1 The GNU Compiler Collection (base package) > ii gccxml 0.9.0+cvs20080525-1 XML output extension to GCC > ii libgcc1 1:4.3.2-1 GCC support library I'm surprised GCC-XML works for you with GCC 4.3. It doesn't for me (I've just checked) and I have the exact same gccxml package, although my gcc packages are the Ubuntu versions. That's why the documentation says to set GCCXML_COMPILER to g++-4.1 or g++-4.2. > However, I have to set the LD_LIBRARY_PATH to be able to run the synth example. I didn't have to do this with gleamsynth-0.0.2.tgz. > > export LD_LIBRARY_PATH=./output/i486-linux-gnu/GleamDrivers:./output/i486-linux-gnu/GleamCore Yep, that is necessary, otherwise the dynamic linker won't find the libraries you've just built. It shouldn't be different with gleamsynth-0.0.2.tgz though. My guess would be that maybe you had the gleam deb package installed at the time, so you were running the executables you built against the libraries that were installed in /usr/lib? I've had that happen to me. > The commandline parser didn't parse the -d option correctly. The "-d hw:1" didn't work. Sorry, yesterday I didn't have time to test that change properly. I've fixed it now, please try again. -- Miguel Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net |
|
From: jimmy <wg...@ya...> - 2009-02-19 23:29:32
|
Hi Miguel,
Previous errors were because I had an older version of pygccxml, I installed pygccxml-1.0.0 and did a new SVN checkout.
The SVN build gave a warning, but did build OK. I don't have the latest packages from Debian Sid (Unstable), but here are the packages' versions from my "dpkg -l | grep gcc" command:
ii gcc 4:4.3.1-1 The GNU C compiler
ii gcc-4.3 4.3.2-1 The GNU C compiler
ii gcc-4.3-base 4.3.2-1 The GNU Compiler Collection (base package)
ii gccxml 0.9.0+cvs20080525-1 XML output extension to GCC
ii libgcc1 1:4.3.2-1 GCC support library
However, I have to set the LD_LIBRARY_PATH to be able to run the synth example. I didn't have to do this with gleamsynth-0.0.2.tgz.
export LD_LIBRARY_PATH=./output/i486-linux-gnu/GleamDrivers:./output/i486-linux-gnu/GleamCore
output/i486-linux-gnu/examples/synth/synth -vv -a alsa -d hw:1 -e alsaseq ~/download/soundfonts/Unison.sf2
The commandline parser didn't parse the -d option correctly. The "-d hw:1" didn't work.
Jimmy
|
|
From: Miguel L. <ml...@gm...> - 2009-02-18 23:37:54
|
I've just implemented in SVN the way of passing the audio device to the driver I described above. Command line tools playmidi and synth can now take a -d switch to specify the audio device, e.g: playmidi -d hw:1 my_midi_file.mid my_soundfont.sf2 I haven't done much testing, so please let me know if you find any problems. -- Miguel Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net |
|
From: Miguel L. <ml...@gm...> - 2009-02-18 21:06:39
|
Hi Jimmy, > How would one build Gleam from SVN? The build instruction only build from the .tgz source, won't build from SVN code for me. > > I am trying to add a public variable to driver.h, trying to test a simple way to pass in the command line option for alsa device selection. But the build command bails on me. How should I go about trying this? The build instructions in Gleam's website are supposed to work for building from SVN too. The only difference should be that if you want to build from SVN you need GCC-XML and pygccxml installed in your system. If building from SVN is not working for you, please post the error messages and we'll see what could be going wrong. > As for Alsa device selection, I see in GleamAlsaAudioDriver::GleamAlsaAudioDriver() of GleamDriver/src/alsaaudio.cpp, > > const char* device = "default"; Yep, that's the ALSA device and yes, changing it to "hw:1" will make ALSA try to open your second sound card. > I don't see Gleam initialization of audio driver(s) allowing parameters. Audio drivers take a parameter of type GleamAudioDriverConfiguration, which contains stuff such as the sample rate or the number of channels (mono/stereo). It would be a matter of adding a "device" field to that structure, and also a command line option to playmidi/synth to set it. > I think this may be needed, and as you add more drivers, there may be more requests for special parameters for each driver. So allowing for programmatically passing in a generic array, or table of (key, value) association of some sort should allow for flexibility. Maybe having special configuration parameters will be required for some drivers, but generally speaking I think it would be best to make configuration parameters as driver-agnostic as possible. Applications using GleamDrivers shouldn't be required to know about the individual drivers in order to take advantage of them. I think having configuration parameters that only exist for some drivers or have different meanings depending on the driver would go against that. > It might be better not to do all initiallization at object instantiation. I would generally do that as 2 separate functions, with optional 3rd usage: > [...] > > I would love to allow for changing everything properly on-the-fly. No real reason to shut down and restart the app just because it was hard-coded in "initialization" step. Well, think about having to rebooting windows half a dozen times for every windows update release, vs. the Unix way. > > With Alsa, Jack connections, restarting the app could cause other logistic problem of reconnecting to/from other apps, too. I think we're talking about two different things here. Deleting the driver object and then creating a different one should be quite possible without exiting the application, and in fact as far as I can see it should work with Gleam already. If it doesn't, let's look to address that. Being able to re-initialise a driver object with a different configuration (as opposed to having to delete the old driver object and then create a new one) wouldn't provide more functionality, it would just save a de-allocation and then an allocation. But that saving is very very small, and the price is some danger that some state might be inadvertently kept through the re-initialisation. In my experience, objects that don't change after initialisation (or change as little as possible) are easiest and safest to work with. Sometimes you need to go in a different route for efficiency reasons, but I don't think this is one of those times. -- Miguel Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net |
|
From: jimmy <wg...@ya...> - 2009-02-18 13:18:21
|
Hi Miguel,
How would one build Gleam from SVN? The build instruction only build from the .tgz source, won't build from SVN code for me.
I am trying to add a public variable to driver.h, trying to test a simple way to pass in the command line option for alsa device selection. But the build command bails on me. How should I go about trying this?
As for Alsa device selection, I see in GleamAlsaAudioDriver::GleamAlsaAudioDriver() of GleamDriver/src/alsaaudio.cpp,
const char* device = "default";
was used when calling Alsa's snd_pcm_open(). If you allow a parameter to be passed via some commandline option as "hw:0", "hw:1" then I think Gleam can use the appropriate Alsa device instead of "default".
I looked this up by searching for "snd_pcm_open" in jackd source file:
jack-audio-connection-kit-0.116.2/tools/alsa_out.c
qjackctl invokes jackd as: " jackd -dalsa -dhw:1 "
I don't see Gleam initialization of audio driver(s) allowing parameters. I think this may be needed, and as you add more drivers, there may be more requests for special parameters for each driver. So allowing for programmatically passing in a generic array, or table of (key, value) association of some sort should allow for flexibility. I am thinking about trying to add a public static variable (or getter setter of a protected static varible) to hold on to a copy of the appropriate command line parameter(s) for this, but the build step fails.
It might be better not to do all initiallization at object instantiation. I would generally do that as 2 separate functions, with optional 3rd usage:
object instantiation
-- then call initialization separately (with, or without parameters)
-- may also allow for re-initialization (with, or without parameters), first closing and clearing out any existing system resources.
This way, command line parameters can be used in the initialization, or re-initialization step separately from instantiation of the driver object.
In fact, the re-initialization function could be the same as the initialization function. Just that many people don't do it that way, because they don't think about it. I would love to allow for changing everything properly on-the-fly. No real reason to shut down and restart the app just because it was hard-coded in "initialization" step. Well, think about having to rebooting windows half a dozen times for every windows update release, vs. the Unix way.
With Alsa, Jack connections, restarting the app could cause other logistic problem of reconnecting to/from other apps, too.
Jimmy
|
|
From: Miguel L. <ml...@gm...> - 2009-02-16 22:19:51
|
> Oops, my bad on the declaration of "priority" in Thread.cpp. Although it would still be the right thing to do there, it doesn't make a difference in the stuttering problem. I was going to check that, but my understanding is that the structure pointed to by the second argument to pthread_attr_setschedparam() doesn't need to remain in existence after the call, so declaring that structure within the same block as the call to pthread_attr_setschedparam() should be fine. -- Miguel Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net |
|
From: jimmy <wg...@ya...> - 2009-02-16 12:17:47
|
> Hi Miguel,
>
> Got it.
>
> Also, I think I made a little progress on the stuttering
> problem. In the file
>
> GleamCore/src/os/thread.cpp
>
> I declared "priority" at the beginning of the
> function, and it seems to work much better for me on a
> 2.4GHz CPU. I may want to try on a slower machine (older
> laptop) eventually.
Hi Miguel,
Oops, my bad on the declaration of "priority" in Thread.cpp. Although it would still be the right thing to do there, it doesn't make a difference in the stuttering problem.
Jimmy
|
|
From: jimmy <wg...@ya...> - 2009-02-16 00:33:16
|
Hi Miguel, This is for archival, documentation... About XG (and GS) program changes, and how missing instruments might be handled, Here are some comments and observations I found around the web. I think missing drum-kits should be handled similarly. >>>>> archive.cs.uu.nl/pub/MIDI/DOC/xg.txt Both specs also operate a scheme of tone 'fallback', whereby if a variation tone is not present at a given bank program number, then the synth will fall back to using the corresponding GM tone. (the GS spec does this in a cascading fashion, i.e. falling back to the next lowest variation tone of the same program number....this can be confusing). The advantage of the fallback scheme is that if a song uses variation tones and is played on a synth of lesser specification (or purely GM specification) then the voicing will still be acceptable (although not ideal). <<<<< >>>>> cybermidi.powweb.com/faq/content/3/22/en/what_s-the-difference-between-gm-gs-and-xg.html Although the XG format defines an extensive range of parameters and allows exceptionally fine musical control, not all XG devices need to conform to the full XG specification. The XG format allows features and capabilities to be "scaled" according to price and target applications. When music data is played on a scaled-down XG device, playback is adapted to the capabilities of the device used. If, for example, a specified voice is not available for a certain part, that part will be played using a similar basic voice. On the other end of the scale, models equipped with a graphic equalizer can be automatically set to play hard rock pieces or classic compositions with appropriate overall EQ. <<<<< >>>>> www.somascape.org/midi/help/intro.html The voices in the extra banks align with those in the standard GM bank, thus providing variants on the standard voices. This means that a MIDI file composed for use with a GS or XG device will sound okay when played using a standard GM device (because a GM device will ignore any Bank Select messages and just respond to the Program Change messages). <<<<< Jimmy |
|
From: jimmy <wg...@ya...> - 2009-02-16 00:03:44
|
--- On Sun, 2/15/09, Miguel Lobo <ml...@gm...> wrote:
> From: Miguel Lobo <ml...@gm...>
> Subject: Re: Gleamsynth 0.0.2 build -- OK
> To: wg...@ya...
> Cc: gle...@li...
> Date: Sunday, February 15, 2009, 2:18 PM
> Hi Jimmy,
>
> > I see in GleamMidiConverter::convertProgramChange()
> the use of
> >
> > converterChannel.selectedPreset =
> > pr->core.pr->midi.getPreset(bank,
> program, channel == GleamMidi::DRUM_CHANNEL);
> >
> > which implies the restriction, or association of Drum
> bank (128) to drum channel.
>
> As you perhaps found, that call goes to
> GleamMidi::getPreset and then
> to GleamSF2Library::getMidiPreset:
>
> GleamPreset* GleamSF2Library::getMidiPreset(int bank, int
> program,
> bool drumPreset)
> {
> if (drumPreset)
> bank = DRUM_BANK;
> int index =
> pr->sortedPresets.find(GleamSF2Preset::SortingKey(bank,
> program));
> return index == -1 ? 0 :
> &pr->presets[index];
> }
>
> So in MIDI channel 10 the bank gets overridden to 128
> irrespective of
> whatever was set by the BANK_SELECT controller (controller
> 0), while
> in the other MIDI channels the bank selected by BANK_SELECT
> is
> respected. This should allow drums on channels other than
> 10, as long
> as those other channels select bank 128 using BANK_SELECT.
>
> --
> Miguel
> Check out Gleam, an LGPL sound synthesizer library, at
> http://gleamsynth.sf.net
Hi Miguel,
Got it.
Also, I think I made a little progress on the stuttering problem. In the file
GleamCore/src/os/thread.cpp
I declared "priority" at the beginning of the function, and it seems to work much better for me on a 2.4GHz CPU. I may want to try on a slower machine (older laptop) eventually.
>>>>>
void GleamThread::start()
{
pthread_attr_t attr;
pthread_attr_init(&attr);
sched_param priority;
if (pr->detach)
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
if (pr->realtime) {
pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
priority.sched_priority = 90;
pthread_attr_setschedparam(&attr, &priority);
}
if (pthread_create(&pr->thread, &attr, gleamThreadRun, this))
core().log()->error(_("Failed to create the thread"));
pr->threadCreated = true;
}
<<<<<
I think declaring "priority" within the if-block effectively made its use invalid outside that if-block. And it doesn't really get used until pthread_create() is called afterward.
I don't remember how to check for thread priority. I'll have to to a web search later to check on it.
Anyway, it improved the stuttering quite a bit. I may get a little audio pauses on switching between windows, but that's not too bad for now.
Jimmy
|
|
From: Miguel L. <ml...@gm...> - 2009-02-15 22:18:11
|
Hi Jimmy,
> I see in GleamMidiConverter::convertProgramChange() the use of
>
> converterChannel.selectedPreset =
> pr->core.pr->midi.getPreset(bank, program, channel == GleamMidi::DRUM_CHANNEL);
>
> which implies the restriction, or association of Drum bank (128) to drum channel.
As you perhaps found, that call goes to GleamMidi::getPreset and then
to GleamSF2Library::getMidiPreset:
GleamPreset* GleamSF2Library::getMidiPreset(int bank, int program,
bool drumPreset)
{
if (drumPreset)
bank = DRUM_BANK;
int index =
pr->sortedPresets.find(GleamSF2Preset::SortingKey(bank, program));
return index == -1 ? 0 : &pr->presets[index];
}
So in MIDI channel 10 the bank gets overridden to 128 irrespective of
whatever was set by the BANK_SELECT controller (controller 0), while
in the other MIDI channels the bank selected by BANK_SELECT is
respected. This should allow drums on channels other than 10, as long
as those other channels select bank 128 using BANK_SELECT.
--
Miguel
Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net
|
|
From: jimmy <wg...@ya...> - 2009-02-14 19:42:55
|
Hi Miguel,
I see in GleamMidiConverter::convertProgramChange() the use of
converterChannel.selectedPreset =
pr->core.pr->midi.getPreset(bank, program, channel == GleamMidi::DRUM_CHANNEL);
which implies the restriction, or association of Drum bank (128) to drum channel.
Rare, but I have seen some uses of drum sets in 2 channels (9+10, or 10+11) at the same time. Which could mean a mixing of, let's say, Jazz drums and Latin drums, both drum sets could be different prog_numb of bank 128. Of course, they could be loaded from different soundfonts, or in the same soundfont. I think I have seen older, or non-standard midis that use drums on channels other than #10 from time to time, too.
Do you think Gleam should deal with bank #128, instead of channel #10? I think dealing with bank#128 would be much more flexible. Unfortunately, this may change in some function parameters. I'd rather it be now than later when more apps are using Gleam.
Jimmy
|
|
From: Miguel L. <ml...@gm...> - 2009-02-09 22:46:45
|
Hi Jimmy,
Glad you had success building the 0.0.2 release. I see you listed
your gccxml and pygccxml versions, but you shouldn't need them (and
they shouldn't get used) to compile a release, only for SVN.
The playmidi and synth executables give you some help if you run them
with the --help option, but I take your point that adding some
examples is probably a good idea.
The stuttering could be due to Gleam using too much CPU. For some
reason the reverb code seems too slow and in fact I have temporarily
disabled it in SVN. If you want to, you can comment out these lines
in sf2voice.cpp to achieve that effect:
/* reverb send */
float reverbSend =
pr->generators[GleamSF2Generator::REVERB].pr->value;
if (reverbSend != 0.0f)
pr->reverb.mixReverb(audioOutput, skip,
iterationSampleCount, reverbSend);
Defaulting to soundbank 0 sounds reasonable, if that's what other MIDI
apps do. I haven't tested it, but it should be possible by, after
these lines in midiconverter.cpp:
converterChannel.selectedPreset =
pr->core.pr->midi.getPreset(bank, program, channel ==
GleamMidi::DRUM_CHANNEL);
appending:
if (converterChannel.selectedPreset == 0)
converterChannel.selectedPreset =
pr->core.pr->midi.getPreset(0, program,
channel == GleamMidi::DRUM_CHANNEL);
It's also true that there is no jack output driver and that there
isn't a way to change the ALSA device from the command line. I would
like to fix those too.
So in summary you pointed a number of things I would like to fix :-),
but I probably won't have time this week. Maybe we should record them
in the tracker so they don't get forgotten:
https://sourceforge.net/tracker/?group_id=214498
By the way, I just went to the SourceForge tracker for Gleam for the
first time and it turns out that there are two bug reports since last
year. Oops. I'll check it regularly now.
Anyway, if you want to look at the code and have any questions I'll be
of course be glad to answer them.
--
Miguel
Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net
|
|
From: Miguel L. <ml...@gm...> - 2008-07-24 08:35:49
|
Gleam 0.0.2 has been released. The details are available at: http://gleamsynth.sf.net/main/node/6 -- Miguel Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net |
|
From: Miguel L. <ml...@gm...> - 2008-05-15 22:25:47
|
Thanks, I'll improve error reporting from the drivers a bit. On Thu, May 15, 2008 at 5:31 PM, Guillaume Pothier <gpo...@gm...> wrote: > Ok, I found it out... my VM had audio disabled! > Here is a patch that gives a more precise error message. > Regards, > g > > > On Thu, May 15, 2008 at 2:39 AM, Guillaume Pothier <gpo...@gm...> wrote: >> Hi, >> I compiled GleamSynth for windows, but I'm getting an error message >> when I run my app: >> Failed to create the DirectSound object. >> >> Any idea what can be causing it? >> >> Regards, >> g >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Gleamsynth-devel mailing list > Gle...@li... > https://lists.sourceforge.net/lists/listinfo/gleamsynth-devel > > -- Miguel Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net |
|
From: Guillaume P. <gpo...@gm...> - 2008-05-15 16:31:06
|
Ok, I found it out... my VM had audio disabled! Here is a patch that gives a more precise error message. Regards, g On Thu, May 15, 2008 at 2:39 AM, Guillaume Pothier <gpo...@gm...> wrote: > Hi, > I compiled GleamSynth for windows, but I'm getting an error message > when I run my app: > Failed to create the DirectSound object. > > Any idea what can be causing it? > > Regards, > g > |
|
From: Guillaume P. <gpo...@gm...> - 2008-05-15 06:39:19
|
Hi, I compiled GleamSynth for windows, but I'm getting an error message when I run my app: Failed to create the DirectSound object. Any idea what can be causing it? Regards, g |
|
From: Miguel L. <ml...@gm...> - 2008-05-07 19:42:29
|
> Would it be possible to also use templates for GleamSynth and > GleamSubSynth instead of adding new API? Making e.g. GleamSynth a template means that if a GleamCore user (such as GleamDrivers) wants to use some fixed point subsynths and some floating point subsynths they would need two separate GleamSynth objects, which makes everything more difficult for them. On the other hand, adding e.g. a new readAudio(GleamFixed<16,16>**) method means that the users get to choose: they can use readAudio(float**) if they want more precision and it is supported in their target CPU, or they can use the fixed-point version otherwise. Both methods should work irrespective of the combination of subsynths compiled into the library. I see using templates in the SF2 subsynth just as a convenience for us to share code between its fixed point and floating point versions. > I'm not very much into C++, how do you create a class wrapper around int? I have attached the beginnings of a GleamFixed class. With any decent compiler, it should be as efficient as the typedef/macro thing, but more type-safe and readable. -- Miguel Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net |
|
From: Guillaume P. <gpo...@gm...> - 2008-05-05 16:07:17
|
I have a midi file with several tracks and I need to sometimes change the preset of all note events of a given track. Actually, there are several ways I could do it without having the track number in the events. A quick and dirty workaround would be to modify my midi files so that the events of each track use a different channel, and then when I load the file I put all the events back into the same channel, but as I do so I record their original channel in some structure. Another possibility would be to pass an additional "int track" argument to GleamMidiLoader.load so that it loads only the events from the given track, with a default value like -1 meaning "all tracks". We would also need a new method that returns the number of tracks in the file. Or maybe pass an array of GleamEventLists instead of a single list, and the loader would dispatch between the lists. What do you think? g On Tue, May 6, 2008 at 7:17 AM, Miguel Lobo <ml...@gm...> wrote: > GleamEvent is meant to be generic and not tied to MIDI semantics (I > plan to implement loading other song formats in the future), but if > the rationale is good we could add a track number field. However, > before deciding if that is the right thing to do, could you expand a > bit more on what you intend to use it for? > > Regards, > Miguel > > > > On Mon, May 5, 2008 at 2:10 AM, Guillaume Pothier <gpo...@gm...> wrote: > > Hi, > > Do you think it would be ok to add a field to GleamEvent that > > indicates the track number of the midi file track that contained the > > event? I can do it if you give me the green light. > > Regards, > > g > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > Don't miss this year's exciting event. There's still time to save $100. > > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > _______________________________________________ > > Gleamsynth-devel mailing list > > Gle...@li... > > https://lists.sourceforge.net/lists/listinfo/gleamsynth-devel > > > > > > -- > Miguel > Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net > |
|
From: Guillaume P. <gpo...@gm...> - 2008-05-05 15:46:42
|
> > A fixed point synth sounds like an interesting idea. It shouldn't > replace the usual floating point synth though, as that would make the > Gleam library have two incompatible interfaces depending on whether > fixed point is enabled or not. Rather, the required API should be > added to GleamSynth and GleamSubSynth (probably just like the existing > functions but replacing float with int). Would it be possible to also use templates for GleamSynth and GleamSubSynth instead of adding new API? > I'm not sure if you're planning to make the existing SF2 subsynth more > general so it can use fixed point, or write a completely new subsynth. I plan to make the existing SF2 subsynth mote general. > supports). The best way to achieve this is to use templates for the > shared code, with the sample type as a template parameter. These > templates could then be instantiated for floating point and/or fixed > point as needed. Also, for fixed point, the sample type could be a > class wrapper around int so you can redefine the arithmetic operators > as required. I'm not very much into C++, how do you create a class wrapper around int? g > > Regards, > Miguel > > > > On Fri, May 2, 2008 at 5:53 PM, Guillaume Pothier <gpo...@gm...> wrote: > > Hi, > > I was starting to think about how to implement fixed-point synthesis > > for Gleam (the reason is that I want to run it on ARM processors that > > do not have floating-point units). > > What about defining a sample_t type, using it instead of float > > wherever you deal with samples, and using #defines to specify if it's > > int or float as well as, maybe, some arithmetic primitives? > > > > Very roughly sketched, it would be something like that (note that I > > have no idea yet what would actually be the needed arithmetic > > primitives): > > > > #ifdef FLOAT_SYNTH > > typedef float sample_t > > #define sample_mul (v1, v2) (v1*v2) > > #else > > typedef int sample_t > > #define sample_mul (v1, v2) (v1*v2/16) > > #endif > > > > Regards, > > g > > > > PS: by the way, I see you implemented reusable sync events, I'll try > > them out soon. > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > Don't miss this year's exciting event. There's still time to save $100. > > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > _______________________________________________ > > Gleamsynth-devel mailing list > > Gle...@li... > > https://lists.sourceforge.net/lists/listinfo/gleamsynth-devel > > > > > > -- > Miguel > Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net > |
|
From: Miguel L. <ml...@gm...> - 2008-05-05 11:17:05
|
GleamEvent is meant to be generic and not tied to MIDI semantics (I plan to implement loading other song formats in the future), but if the rationale is good we could add a track number field. However, before deciding if that is the right thing to do, could you expand a bit more on what you intend to use it for? Regards, Miguel On Mon, May 5, 2008 at 2:10 AM, Guillaume Pothier <gpo...@gm...> wrote: > Hi, > Do you think it would be ok to add a field to GleamEvent that > indicates the track number of the midi file track that contained the > event? I can do it if you give me the green light. > Regards, > g > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Gleamsynth-devel mailing list > Gle...@li... > https://lists.sourceforge.net/lists/listinfo/gleamsynth-devel > -- Miguel Check out Gleam, an LGPL sound synthesizer library, at http://gleamsynth.sf.net |
