swami-devel — Swami developement list

[Swami-devel] Author of Swami now working on a new software synthesizer

[Element G. <el...@ky...>]

Music and audio software has been a passion of mine for decades now.
Swami, and it's predecessor The Smurf SoundFont Editor, were long in the
making and once my primary focus.  Sometimes life leads one down different
paths though and I found myself having to put aside what once was so
important to me.

While I enjoyed playing with SoundFont instruments, I often was frustrated
by some of the shortcomings of sample based audio.  The amount of effort
necessary to create high quality instruments is rather daunting and
requires audio samples across the entire keyboard, in order to limit the
artifacts from pitch scaling sampled data.  Even then, it is very difficult
to maintain a consistency from one sample to the next.  For many of the
sounds I was experimenting with, I found it most rewarding to extract small
waveforms from sounds I recorded to use as a looped periodic waveform.
Having only a single sample though, greatly limits the usable range of the
instrument.

Two years ago, I felt compelled to get back into music and audio software.
I spent quite a bit of time working on a GTK3 port of Swami, but eventually
abandoned the effort out of frustration.  It then occurred to me that I
should focus on what I had long envisioned to be an ideal synthesis
architecture for instruments.  This new instrument format would be based on
vector curves with a dynamic synthesis architecture.  Such a format would
be able to overcome many of the issues with sample formats and be a good
balance between the time domain and frequency domains.  With increased
computational power, this has become much more feasible than it once was.

After these past 2 years of development, I'm very excited to announce the
website launch of a new company called Kymorphia, a public benefit
corporation.  One of the issues I faced with Swami, was a conflict with the
need to have a day job.  My goal with these new projects is to strike a
good balance between free products/services and commercial offerings, in
order to fund development.  Our premier application called Alkimiya is now
in beta and will be offered for free as a Community Edition (Linux only)
and a Demo Edition for Windows and Mac (soon!).  These versions have some
synthesis limits and the Demo Edition lacks save support.  Purchasing the
unlimited Power Edition will help fund development and will be available
for all 3 OS platforms.

The format we have created is called the Kymorphia Vector Instrument
format.  It is still in development, but already has many exciting
features.  It has a dynamic synthesis model utilizing a tree structure of
waveform curves.  Curves represent periodic waveforms which can be looped
and have an X axis input and a Y axis amplitude input.  An audio signal
waveform for example would usually use Pitch as the X axis input and Volume
as the Y axis multiplier.  These inputs can themselves be dynamic signals,
providing vibrato, and tremolo effects using arbitrary curve waveforms.  By
modeling this as a tree, the effect of a waveform on attributes can be
controlled in an intuitive way.  Attributes include things like: Time (wall
clock time), Pitch, Volume, Balance, Latitude (for front/back surround
sound mixing), and other effects.  Currently there are 3 different filter
types (Low Pass, High Pass, and Band Pass) and a pseudo random noise
generator which is useful for hi-hat sounds.  We will also be adding full
surround sound support soon, with customizable speaker mapping curves.

One of the most notable features of this format is waveform morphing.  This
provides a way to morph a curve from one waveform to one or more other
waveforms.  The morph effect is itself an attribute, which can be
modulated.  This provides for some really amazing sounding instruments and
I'm really looking forward to seeing and hearing what others come up with.
One planned feature is to add support for importing sample data for curve
tracing purposes, in order to be able to model vector instruments after
recorded sounds.

We have many other projects and products planned, including Wave One, which
will be our first standalone Kymorphia Vector Instrument hardware
synthesizer.  We will also be creating an online instrument database soon,
which Alkimiya will be able to directly interface with, so users can share
instruments for free or commercially.

Although these projects aren't open source, we aim to have some of the same
community spirit in what we have to offer.  I hope you'll come check out
the results of our efforts and become a part of the community we are
creating.

Best regards,

Element Green

[Swami-devel] Swami segfaults on start in Ubuntu 18.04 and Fedora 27

[S. C. C. <s.c...@gm...>]

Attempting to start the distro-packaged version of Swami in Ubuntu 18.04 
or Fedora 27 results in a segfault on launch. The only terminal output is:

> libswami-Message: 18:38:27.638: Loading plugins from /usr/lib/swami
> libswami-Message: 18:38:27.702: Loaded 4 plugins
> Segmentation fault (core dumped)
Just to make sure it wasn't something with my system, I tried using a 
fresh Xubuntu 18.04 install in VirtualBox, but the result is the same. 
Here is the Fedora bug report 
<https://bugzilla.redhat.com/show_bug.cgi?id=1541394>.

-~Chris

Re: [Swami-devel] Bug#885778: swami: Depends on libgnomecanvas

[Element G. <el...@el...>]

Thank you for the info.  Should give me enough time to do the port.

Best regards,

Element


On Mon, Jan 1, 2018 at 11:47 AM, Jaromír Mikeš <mir...@gm...> wrote:

>
>
> 2018-01-01 18:34 GMT+01:00 Element Green <jg...@us...>:
>
>> Hello Mira,
>>
>> While I do plan on porting Swami to GTK3 at some point, it is not a
>> trivial task and I haven't had much time for it.  I'll definitely keep this
>> in mind in regards to Debian removing it if it isn't ported and prioritize
>> this accordingly.  When would a port need to be completed in order to
>> continue to be a part of Debian?
>>
>> Best regards,
>>
>> Element
>>
>
> ​Hello Joshua,
>
> thank you for reply ... release date for Buster wasn't set yet but I guess
> it will be sometime about June 2019 ...
> so there is a time.
>
> best regards
>
> mira​
>
>

Re: [Swami-devel] Bug#885778: swami: Depends on libgnomecanvas

[Jaromír M. <mir...@gm...>]

2018-01-01 18:34 GMT+01:00 Element Green <jg...@us...>:

> Hello Mira,
>
> While I do plan on porting Swami to GTK3 at some point, it is not a
> trivial task and I haven't had much time for it.  I'll definitely keep this
> in mind in regards to Debian removing it if it isn't ported and prioritize
> this accordingly.  When would a port need to be completed in order to
> continue to be a part of Debian?
>
> Best regards,
>
> Element
>

​Hello Joshua,

thank you for reply ... release date for Buster wasn't set yet but I guess
it will be sometime about June 2019 ...
so there is a time.

best regards

mira​

Re: [Swami-devel] Bug#885778: swami: Depends on libgnomecanvas

[Element G. <jg...@us...>]

Hello Mira,

While I do plan on porting Swami to GTK3 at some point, it is not a trivial
task and I haven't had much time for it.  I'll definitely keep this in mind
in regards to Debian removing it if it isn't ported and prioritize this
accordingly.  When would a port need to be completed in order to continue
to be a part of Debian?

Best regards,

Element

On Fri, Dec 29, 2017 at 3:29 PM, Jaromír Mikeš <mir...@gm...> wrote:

>
>
> 2017-12-29 21:12 GMT+01:00 Jeremy Bicha <jb...@de...>:
>
>> Source: swami
>> Version: 2.0.0+svn389-5
>> Severity: important
>> User: pkg...@li...
>> Usertags: oldlibs libgnomecanvas
>> Tags: sid buster
>>
>> As announced [1], we do not intend to release Debian 10 "Buster" with
>> the old libgnome (and related) libraries. These libraries have been
>> deprecated and unmaintained for several years.
>>
>> Your package depends and or build-depends on libgnomecanvas.
>>
>> Please port your package to GTK3 and related maintained libraries.
>> Otherwise, please consider requesting that your package be removed from
>> Debian to help us complete this goal.
>>
>> [1] https://lists.debian.org/debian-devel/2017/10/msg00299.html
>
>
> ​Hi ​Joshua,
>
> as you see swami needs to be ported to GTK3 otherwise will be removed from
> debian
> with next debian release.
> Please let me know if there is a plan such update.
>
> best regards
>
> mira
>

Re: [Swami-devel] Bug#885778: swami: Depends on libgnomecanvas

[Jaromír M. <mir...@gm...>]

2017-12-29 21:12 GMT+01:00 Jeremy Bicha <jb...@de...>:

> Source: swami
> Version: 2.0.0+svn389-5
> Severity: important
> User: pkg...@li...
> Usertags: oldlibs libgnomecanvas
> Tags: sid buster
>
> As announced [1], we do not intend to release Debian 10 "Buster" with
> the old libgnome (and related) libraries. These libraries have been
> deprecated and unmaintained for several years.
>
> Your package depends and or build-depends on libgnomecanvas.
>
> Please port your package to GTK3 and related maintained libraries.
> Otherwise, please consider requesting that your package be removed from
> Debian to help us complete this goal.
>
> [1] https://lists.debian.org/debian-devel/2017/10/msg00299.html


​Hi ​Joshua,

as you see swami needs to be ported to GTK3 otherwise will be removed from
debian
with next debian release.
Please let me know if there is a plan such update.

best regards

mira

[Swami-devel] Loop release mode broken in .sf2 files

[Jonathan H. <jh...@ho...>]

Hi,

I noticed that a "release" type loop was marked "standard" when loaded 
into swami 2.0.0. Adjusting the loop type would prevent it from working 
in release mode again.

I found the problem stemmed from libinstpatch/IpatchSF2Gen.h:
"IPATCH_SF2_GEN_SAMPLE_MODE_LOOP_RELEASE = 1 << 1"

The SF2 spec says that 3 is the correct value:
"54 sampleModes... 2 is unused but should be interpreted as indicating 
no loop, and 3 indicates a sound which loops for the
duration of key depression then proceeds to play the remainder of the 
sample."

Changing the definition above from 2 to 3 and rebuilding libinstpatch 
fixed it for me.

Jonathan

Re: [Swami-devel] Handling stereo SoundFont samples

[Element G. <el...@el...>]

On Fri, Aug 19, 2016 at 9:53 AM, S. Christian Collins <
s.c...@gm...> wrote:

> On 08/19/2016 12:28 AM, Element Green wrote:
>
> I think FluidSynth is pretty good about starting all the voices created by
> a note-on event in the same synthesis period, which would keep them in sync
> if their pitch related parameters are the same.  My point was, that if
> there are differences in the pitch related parameters (or loop parameters)
> between the left and right samples, they will get out of sync.  In this
> sense, the SoundFont standard is not being followed, as it is written,
> since these parameters should be forced to be the same.
>
>
> Hmm... I am currently working on a piano instrument in SoundFont format
> that features stereo samples. To avoid phase cancellation when the stereo
> field is altered, I have been shifting one of the channels back several
> samples so that the fundamental vibrations align. However, this means that
> in order to maintain the original loop, I must also shift the loop points
> an amount equal to the number of samples that channel was shifted,
> resulting in loop points that are not identical between the left and right
> channels. I have yet to run into this being a problem with either the
> Audigy or FluidSynth. If I converted the stereo samples to individual L and
> R mono samples instead, I would lose the link between the two when
> voice-stealing comes into play. What do you think about this scenario?
>
>

It may be that the loop points aren't actually considered as part of the
"pitch" parameters.  The standard really doesn't seem to be specific enough
in defining this and I noted previously in this thread that there are some
issues as well in regards to potential conflicts with the envelopes and
LFOs in this regard.  Good point about the lack of an L/R link causing
voice stealing to not work properly.  Seems like some review of the
FluidSynth code in this regard is also in order, as to how it matches these
if there are multiple pairs.


However if there are any SoundFont files out there, which have differences
> in the pitch parameters between left/right pairs and assume that they will
> be forced to be the same by the synthesizer, then these SoundFont
> instruments will not behave as expected.
>
>
> I wonder how many SoundFont designers would work under this assumption,
> though. I certainly didn't know about these limitations until you mentioned
> it. None of my SoundFont editors ever restricted me from changing pitch,
> loop points, etc. between the L and R samples of a stereo pair, and the
> synthesizers always seemed to oblige. I am going by memory, though...
> perhaps I should test this in more detail to see how everything behaves.
>
>

This may be a case of real life implementations not really following what
is in the specification.  Testing of other applications would prove to be
very useful to confirm this and also get an idea of "best practice".


-~Chrisd
>


Cheers!

Element

Re: [Swami-devel] Handling stereo SoundFont samples

[S. C. C. <s.c...@gm...>]

On 08/19/2016 12:28 AM, Element Green wrote:
> I think FluidSynth is pretty good about starting all the voices 
> created by a note-on event in the same synthesis period, which would 
> keep them in sync if their pitch related parameters are the same.  My 
> point was, that if there are differences in the pitch related 
> parameters (or loop parameters) between the left and right samples, 
> they will get out of sync.  In this sense, the SoundFont standard is 
> not being followed, as it is written, since these parameters should be 
> forced to be the same.

Hmm... I am currently working on a piano instrument in SoundFont format 
that features stereo samples. To avoid phase cancellation when the 
stereo field is altered, I have been shifting one of the channels back 
several samples so that the fundamental vibrations align. However, this 
means that in order to maintain the original loop, I must also shift the 
loop points an amount equal to the number of samples that channel was 
shifted, resulting in loop points that are not identical between the 
left and right channels. I have yet to run into this being a problem 
with either the Audigy or FluidSynth. If I converted the stereo samples 
to individual L and R mono samples instead, I would lose the link 
between the two when voice-stealing comes into play. What do you think 
about this scenario?

> However if there are any SoundFont files out there, which have 
> differences in the pitch parameters between left/right pairs and 
> assume that they will be forced to be the same by the synthesizer, 
> then these SoundFont instruments will not behave as expected.

I wonder how many SoundFont designers would work under this assumption, 
though. I certainly didn't know about these limitations until you 
mentioned it. None of my SoundFont editors ever restricted me from 
changing pitch, loop points, etc. between the L and R samples of a 
stereo pair, and the synthesizers always seemed to oblige. I am going by 
memory, though... perhaps I should test this in more detail to see how 
everything behaves.

-~Chrisd

Re: [Swami-devel] Handling stereo SoundFont samples

[Element G. <el...@el...>]

Hello Christian!

Thank you for the feedback, very helpful.

On Tue, Aug 9, 2016 at 11:03 PM, S. Christian Collins <
s.c...@gm...> wrote:

> On 08/01/2016 12:26 AM, Element Green wrote:
>
> One thing I had started to work on, but I think at this point am going to
> scrap, is changing Swami and libInstPatch to treat stereo SoundFont samples
> as a single item (rather than 2 separate items representing the left and
> right channels).  I made the decision to scrap this idea, after observing a
> lot of discrepancies in SoundFont files in regards to the specification,
> which overly complicates things in regards to combining separate channels
> into 1 item.
>
>
> Yes, I can see how this would be tricky. I will sometimes use the left or
> right sample orphaned from its stereo pair to create a certain effect or
> instrument variation. I didn't know this was supposed to be a no-no. Even
> when using stereo pairs, I will sometimes have different settings for the L
> and R samples, often to deal with discrepancies in the samples (e.g., one
> channel too loud, or needs to go through the low-pass filter).
>
>

According to the standard only the pitch related settings are forced to be
the same for both channels, the rest of the non pitch parameters can have
independent settings between channels.


> What sort of improvements would you want to see with Swami as far as how
> stereo samples are currently treated in the user interface?  For example,
> when changing parameters, often it is desirable to change the parameter
> identically on both left and right channels of a stereo pair.  Anyone have
> any ideas on how to allow the interface to be able to change parameters on
> both channels or one or the other individually?
>
> Some thoughts off the top of my head:
> 1. Have a checkbox somewhere titled "Lock stereo samples" or something
> which causes changes to one sample to also affect the other channel (in
> instrument zones or samples).  This would include note and velocity ranges
> as well.  Not sure the best way to indicate when there are existing
> differences in parameters between channels though.
>
>
> Perhaps you could indicate the differences by filling the entry box for
> the parameter with a hash pattern or something and a grayed-out slider. If
> the user clicks the slider or types into the entry box, then it would set
> those values for both samples. This could apply as well to whenever
> multiple samples are selected, as you mention in item #2.
>
>

I may create some custom widgets for this.  I've been kicking around the
idea anyways, even without the "change multiple objects" feature.

2. Provide a generic means to change the parameters of multiple items.
> This would be great anyways, and could be extended to stereo pairs.
> Selecting both of the samples of a stereo pair would allow for changing
> parameters for both.  This would probably require some creativity as to how
> to represent multiple differing values with standard widgets (may have to
> create new custom range widgets or have some other indicators).  Perhaps
> the "Lock stereo samples" option could still exist in the interface which
> causes both items of a stereo pair to be selected when one of them is
> clicked.
>
> As I'm writing this, I'm liking option #2.
>
>
> I think option #2 is overall the most useful from an instrument design
> perspective. There are so many times when selecting multiple samples and
> giving them all the same attack, for example, would save a lot of time. If
> you're only able to implement one of these options, it would be #2 without
> question. Also implementing #1 would just be icing on the cake.
>
>

I agree.  I think implementing the 2nd option (a generic way to change
parameters of multiple items) is the best and it would be easy to add an
option for the first one to leverage off of this same feature.  Only the
sample viewer would need some additional smarts to show the sample as
stereo in this case.


<<snip>>
>
> #2: From what I can tell FluidSynth has no code to ensure #2.  Both
> FluidSynth and Swami treat each instrument zone individually and does not
> try to ensure any synchronization between the samples (for example you can
> freely change the loop of both channels, pitch, etc and they will be out of
> sync).  While this may indeed lead to incompatibilities between other
> SoundFont synthesizers, I don't inherently see an issue with it.  That may
> be issue enough though.  I wonder how many SoundFont files make the
> assumption that #2 will be adhered to and have different values between the
> two zones of a stereo sample.
>
>
> My understanding of #2 was that the samples would at least be guaranteed
> to start exactly simultaneously. With a normally-played stereo sample, this
> would ensure that one of the two channels would never start behind the
> other. Even a few samples off in starting time can cause phase issues
> between L and R samples.
>
>

I think FluidSynth is pretty good about starting all the voices created by
a note-on event in the same synthesis period, which would keep them in sync
if their pitch related parameters are the same.  My point was, that if
there are differences in the pitch related parameters (or loop parameters)
between the left and right samples, they will get out of sync.  In this
sense, the SoundFont standard is not being followed, as it is written,
since these parameters should be forced to be the same.

<<snip>>
>
> #4: I see this rule also broken quite frequently as well, where a stereo
> pair is layered with the same note/velocity range (layered).  Wouldn't
> normally seem like an issue, except for rule #2, since one cannot be sure
> what is the other matching zone of a stereo pair (there is nothing about
> order of zones being any indicator).
>
>
> Stereo pairs are usually be found in SoundFonts as consecutive zones
> (usually the L sample first, then R). So I guess in the case of multiple
> copies of the same stereo pair within an instrument, I would just group
> them as they show up from top to bottom in the list of sample zones.
>
>

Probably a safe assumption.  If FluidSynth is just left to not treat stereo
pairs specially, then this becomes a non issue though.  However if there
are any SoundFont files out there, which have differences in the pitch
parameters between left/right pairs and assume that they will be forced to
be the same by the synthesizer, then these SoundFont instruments will not
behave as expected.


The easiest thing to do is to not follow any of these rules and treat the
> channels of a stereo pair completely independently.  This provides maximum
> flexibility, but could lead to synthesis incompatibilities.  Helpful
> interfaces could still be provided in Swami though to aid in synchronizing
> parameters between stereo pairs and also potentially warning when certain
> rules are being broken.
>
>
> I would say the most important matters of handling of L and R samples
> would be:
>
>    1. The L and R samples should begin playback at exactly the same time.
>    But then, shouldn't all of the samples in an instrument start at the same
>    time?
>
> Yes, I believe this is the case.

>
>    1. Note-cutoff logic should never cut off just one voice of a stereo
>    pair. Both the L and R samples should be cut off together.
>
> I think this may hold true as well, though I'm not positive.  I seem to
recall something related to checking for stereo pairs in the voice killing
algorithm.

>
>    1. if one sample of a stereo pair is used, then its pair will be the
>    next matching sample in the list of sample zones (from top to bottom as it
>    displayed in list form).
>    2. If a stereo pair does not have matching key and velocity ranges,
>    they should be treated as individual (mono) samples.
>    3. If a sample is used in isolation from its stereo pair, it should be
>    treated as a mono sample.
>
>
> That's all I can think of for now. I hope this is helpful.
>
>

It was.  Thank you for your input.  I'm leaning towards the idea of just
treating all samples as mono, with some assistance in Swami to aid the user
in changing "pitch" related parameters and loop settings on both samples by
default.  There are a lot of rules about how parameters should be set.  My
goal has been to allow the maximum flexibility and add features for
checking for issues on demand (or on save).



> -~Chris
>

Best regards,

Element

Re: [Swami-devel] Handling stereo SoundFont samples

[S. C. C. <s.c...@gm...>]

On 08/01/2016 12:26 AM, Element Green wrote:
> One thing I had started to work on, but I think at this point am going 
> to scrap, is changing Swami and libInstPatch to treat stereo SoundFont 
> samples as a single item (rather than 2 separate items representing 
> the left and right channels).  I made the decision to scrap this idea, 
> after observing a lot of discrepancies in SoundFont files in regards 
> to the specification, which overly complicates things in regards to 
> combining separate channels into 1 item.

Yes, I can see how this would be tricky. I will sometimes use the left 
or right sample orphaned from its stereo pair to create a certain effect 
or instrument variation. I didn't know this was supposed to be a no-no. 
Even when using stereo pairs, I will sometimes have different settings 
for the L and R samples, often to deal with discrepancies in the samples 
(e.g., one channel too loud, or needs to go through the low-pass filter).

> What sort of improvements would you want to see with Swami as far as 
> how stereo samples are currently treated in the user interface?  For 
> example, when changing parameters, often it is desirable to change the 
> parameter identically on both left and right channels of a stereo 
> pair.  Anyone have any ideas on how to allow the interface to be able 
> to change parameters on both channels or one or the other individually?
>
> Some thoughts off the top of my head:
> 1. Have a checkbox somewhere titled "Lock stereo samples" or something 
> which causes changes to one sample to also affect the other channel 
> (in instrument zones or samples).  This would include note and 
> velocity ranges as well.  Not sure the best way to indicate when there 
> are existing differences in parameters between channels though.

Perhaps you could indicate the differences by filling the entry box for 
the parameter with a hash pattern or something and a grayed-out slider. 
If the user clicks the slider or types into the entry box, then it would 
set those values for both samples. This could apply as well to whenever 
multiple samples are selected, as you mention in item #2.

> 2. Provide a generic means to change the parameters of multiple 
> items.  This would be great anyways, and could be extended to stereo 
> pairs.  Selecting both of the samples of a stereo pair would allow for 
> changing parameters for both. This would probably require some 
> creativity as to how to represent multiple differing values with 
> standard widgets (may have to create new custom range widgets or have 
> some other indicators).  Perhaps the "Lock stereo samples" option 
> could still exist in the interface which causes both items of a stereo 
> pair to be selected when one of them is clicked.
>
> As I'm writing this, I'm liking option #2.

I think option #2 is overall the most useful from an instrument design 
perspective. There are so many times when selecting multiple samples and 
giving them all the same attack, for example, would save a lot of time. 
If you're only able to implement one of these options, it would be #2 
without question. Also implementing #1 would just be icing on the cake.

> <<snip>>
>
> #2: From what I can tell FluidSynth has no code to ensure #2.  Both 
> FluidSynth and Swami treat each instrument zone individually and does 
> not try to ensure any synchronization between the samples (for example 
> you can freely change the loop of both channels, pitch, etc and they 
> will be out of sync).  While this may indeed lead to incompatibilities 
> between other SoundFont synthesizers, I don't inherently see an issue 
> with it.  That may be issue enough though.  I wonder how many 
> SoundFont files make the assumption that #2 will be adhered to and 
> have different values between the two zones of a stereo sample.

My understanding of #2 was that the samples would at least be guaranteed 
to start exactly simultaneously. With a normally-played stereo sample, 
this would ensure that one of the two channels would never start behind 
the other. Even a few samples off in starting time can cause phase 
issues between L and R samples.

> <<snip>>
>
> #4: I see this rule also broken quite frequently as well, where a 
> stereo pair is layered with the same note/velocity range (layered).  
> Wouldn't normally seem like an issue, except for rule #2, since one 
> cannot be sure what is the other matching zone of a stereo pair (there 
> is nothing about order of zones being any indicator).

Stereo pairs are usually be found in SoundFonts as consecutive zones 
(usually the L sample first, then R). So I guess in the case of multiple 
copies of the same stereo pair within an instrument, I would just group 
them as they show up from top to bottom in the list of sample zones.

> The easiest thing to do is to not follow any of these rules and treat 
> the channels of a stereo pair completely independently.  This provides 
> maximum flexibility, but could lead to synthesis incompatibilities.  
> Helpful interfaces could still be provided in Swami though to aid in 
> synchronizing parameters between stereo pairs and also potentially 
> warning when certain rules are being broken.

I would say the most important matters of handling of L and R samples 
would be:

 1. The L and R samples should begin playback at exactly the same time.
    But then, shouldn't all of the samples in an instrument start at the
    same time?
 2. Note-cutoff logic should never cut off just one voice of a stereo
    pair. Both the L and R samples should be cut off together.
 3. if one sample of a stereo pair is used, then its pair will be the
    next matching sample in the list of sample zones (from top to bottom
    as it displayed in list form).
 4. If a stereo pair does not have matching key and velocity ranges,
    they should be treated as individual (mono) samples.
 5. If a sample is used in isolation from its stereo pair, it should be
    treated as a mono sample.


That's all I can think of for now. I hope this is helpful.

-~Chris

[Swami-devel] Handling stereo SoundFont samples

[Element G. <el...@el...>]

Hello Swami development list,

It's been a while since my last emails.  I've been working on Swami and
libInstPatch from time to time and primarily focusing on the Python GObject
Introspection binding, creating a Python test suite to help find and fix
bugs, and improving the libInstPatch API.

One thing I had started to work on, but I think at this point am going to
scrap, is changing Swami and libInstPatch to treat stereo SoundFont samples
as a single item (rather than 2 separate items representing the left and
right channels).  I made the decision to scrap this idea, after observing a
lot of discrepancies in SoundFont files in regards to the specification,
which overly complicates things in regards to combining separate channels
into 1 item.  At this point I think the most helpful would be to get some
user interface input from others who have experience using other SoundFont
editors as far as stereo samples are concerned.

What sort of improvements would you want to see with Swami as far as how
stereo samples are currently treated in the user interface?  For example,
when changing parameters, often it is desirable to change the parameter
identically on both left and right channels of a stereo pair.  Anyone have
any ideas on how to allow the interface to be able to change parameters on
both channels or one or the other individually?

Some thoughts off the top of my head:
1. Have a checkbox somewhere titled "Lock stereo samples" or something
which causes changes to one sample to also affect the other channel (in
instrument zones or samples).  This would include note and velocity ranges
as well.  Not sure the best way to indicate when there are existing
differences in parameters between channels though.

2. Provide a generic means to change the parameters of multiple items.
This would be great anyways, and could be extended to stereo pairs.
Selecting both of the samples of a stereo pair would allow for changing
parameters for both.  This would probably require some creativity as to how
to represent multiple differing values with standard widgets (may have to
create new custom range widgets or have some other indicators).  Perhaps
the "Lock stereo samples" option could still exist in the interface which
causes both items of a stereo pair to be selected when one of them is
clicked.

As I'm writing this, I'm liking option #2.

The remainder of this email is some background on SoundFont files and
stereo pairs and some of my findings which lead me to rethink this issue,
if anyone is interested..

Cheers!

Element


<SemiTechnicalAndVerbose>

Stereo samples are stored in SoundFont files as 2 separate mono samples
which have flags that indicate if they are the left or right channels of
the pair.  In addition any instrument which references a stereo sample will
usually have 2 instrument zones, one pointing to the left channel and one
pointing to the right channel.  This means that instrument zone generators
can differ between the left and right channels.  This is on thing that
complicates matters.

The SoundFont specification defines some restrictions on stereo samples:

1. Both channels should be referenced in an instrument (should not have
just one channel of a stereo pair).
2. Right sample zone pitch related generators are supposed to be used to
play the stereo sample, ensuring the left and right channel play in a
synchronized manner.
3. All other non-pitch generators are applied on an individual channel
basis.
4. Instruments should be designed where no more than 1 instance of a given
stereo sample can be activated simultaneously.

All that may sound fine and dandy, but I scanned through a bunch of
SoundFont files and found most of these rules being broken and the other
rules are not well defined.

I'll take each one of those in turn:

#1: I find lots of instances of only 1 channel of a stereo pair being used
in instruments (for example in the 128mb Fluid SoundFont).  Doesn't seem
like that big of a deal really.

#2: From what I can tell FluidSynth has no code to ensure #2.  Both
FluidSynth and Swami treat each instrument zone individually and does not
try to ensure any synchronization between the samples (for example you can
freely change the loop of both channels, pitch, etc and they will be out of
sync).  While this may indeed lead to incompatibilities between other
SoundFont synthesizers, I don't inherently see an issue with it.  That may
be issue enough though.  I wonder how many SoundFont files make the
assumption that #2 will be adhered to and have different values between the
two zones of a stereo sample.

#3: What exactly is the complete set of pitch related generators in the
first place?  I would assume this would mean loop related parameters,
tuning, vibrato LFO, etc.  But what about the modulation LFO and envelope?
A conflict can easily occur for example if the modulation LFO has different
frequency settings and is controlling pitch and filter cutoff in separate
stereo pairs (how can a single LFO be used at 2 different frequencies, one
to supply the same frequency pitch modulation and the other to modulate the
filter cutoff?).  So I would think that would necessitate that the
modulation LFO and envelope are also used from only the right channel.

#4: I see this rule also broken quite frequently as well, where a stereo
pair is layered with the same note/velocity range (layered).  Wouldn't
normally seem like an issue, except for rule #2, since one cannot be sure
what is the other matching zone of a stereo pair (there is nothing about
order of zones being any indicator).

The easiest thing to do is to not follow any of these rules and treat the
channels of a stereo pair completely independently.  This provides maximum
flexibility, but could lead to synthesis incompatibilities.  Helpful
interfaces could still be provided in Swami though to aid in synchronizing
parameters between stereo pairs and also potentially warning when certain
rules are being broken.

</SemiTechnicalAndVerbose>

Re: [Swami-devel] Character encodings

[Element G. <el...@el...>]

I'm thinking actually of #1, which I believe fits in with what you
described.  I agree that UTF-8 should not be stored in a standard which
says nothing about doing that.  It is quite likely SF2 predated UTF-8 (well
at least I don't remember UTF-8 being around when I was first playing with
the standard).  What I was referring to with the differences between choice
#1 and #3 is that in both cases characters would just be stored as ASCII in
the file, but in #1, libInstPatch would convert the incoming data to UTF-8
to provide a consistent interface to Swami.  The data would then get
converted from UTF-8 back to ASCII when saving.  To get around the issue
you mentioned about characters which can't be converted, properties could
be added for introspecting the character encoding and the GUI could make
sure not to store these.  I think that should work well.

Something I have been thinking about lately is what sample based file
formats would be good to add to Swami.  SFZ looks like one which may be
fairly popular.  I wonder what other ones might be useful to have editing
support for.  There may also be ones which are better just to have read
support for, for converting to other formats for example.

Cheers!

Element

On Wed, Jul 6, 2016 at 7:00 AM, Aaron Laws <dar...@gm...> wrote:

> On Wed, Jul 6, 2016 at 4:37 AM, Element Green <el...@el...
> > wrote:
>
>> I did some investigation in regards to the invalid UTF-8 string issues.
>> Examining the names of the instruments in the Jeux14.sf2 SoundFont reveals
>> that they are encoded as ISO-8859-1 strings (basically the extended ASCII
>> set).
>>
>> At this point I am undecided as to the best way to deal with this.  I see
>> a couple of options:
>> 1. Convert the strings to/from UTF-8 when the SoundFont is loaded/saved
>> (preserving the regular extended ASCII character set in SoundFont files)
>> 2. Convert the strings to UTF-8 when loading and store them as UTF-8 on
>> saving.
>> 3. Leave the names as is, but convert them in the GUI.
>>
>> I could see option 1 as probably being the best option, but it wouldn't
>> work for characters that aren't part of the limited ISO-8859-1 character
>> set.  Ideally this would be prevented on the user input side of things.
>>
>> Option 2 seems problematic for a number of reasons.  While this option
>> would provide the most flexibility in what characters could be stored to
>> SoundFont files, there likely would be issues with other programs accessing
>> them though (I question whether any UTF-8 encoded SoundFont files can be
>> found in the wild - some investigation is in order).  The other issue is
>> that converting could result in longer names which might get truncated in
>> the limited character width of names in SoundFont files.
>>
>> Option 3 would lead to the issue where different files types would end up
>> having different encodings in the libInstPatch API.  It would be nice to
>> present a common interface to libInstPatch for any instrument file format.
>>
>> At any rate, thought I'd solicit some input from the swami-devel list.
>>
>> Cheers!
>>
>> Element
>>
>>
> Oh yeah, for what it's worth, when I delete one of the replacement
> characters while editing an instrument name, etc., several of the following
> characters are deleted. I expect any work you do in this area will correct
> that behaviour, but I wanted to note it now.
>
> As a recent addition to the swami-devel list myself, I'll offer an
> opinion. If this is the specification:
> http://freepats.zenvoid.org/sf2/sfspec24.pdf, I think storing any unicode
> (UTF-8 or otherwise) is not a good idea. The spec speaks of ASCII a good
> deal, but doesn't seem to know anything about unicode. It seems to be an
> old standard from the days when "ASCII" was "good enough". Of course,
> "ASCII" is not good enough, and leaves many questions unanswered. I don't
> see an allowable character set in the spec, either. This leaves us asking:
> are tabs allowed? What about line-feed? Terminal Bell (0x7)? And extended
> characters (this is the current question, I believe) past 128?
>
> I tend to be very restrained when interpreting standards, etc., so I would
> vote for option 3. Strings in this spec should be treated as "ASCII". There
> is no way to signal to the file interpreter that any other encoding is
> present. Of course, what is done with them in the GUI has little to do with
> the standard, but UTF-8 seems expedient. You'll also have to deal with a
> user inputting, say, checkmark (
> http://www.fileformat.info/info/unicode/char/2713/index.htm), then trying
> to save it. Perhaps an error earlier (when the user performs the input)
> rather than later (at file-save time) would be better.
>
> In case it helps, you can see the "stop list" for jeux 1.4:
> http://www.realmac.info/grenade1.htm to make sure you're getting the
> right characters.
>
> From my perspective, you're doing excellent work; thanks!
>
> In Christ,
> Aaron Laws
>

Re: [Swami-devel] Character encodings

[Aaron L. <dar...@gm...>]

On Wed, Jul 6, 2016 at 4:37 AM, Element Green <el...@el...>
wrote:

> I did some investigation in regards to the invalid UTF-8 string issues.
> Examining the names of the instruments in the Jeux14.sf2 SoundFont reveals
> that they are encoded as ISO-8859-1 strings (basically the extended ASCII
> set).
>
> At this point I am undecided as to the best way to deal with this.  I see
> a couple of options:
> 1. Convert the strings to/from UTF-8 when the SoundFont is loaded/saved
> (preserving the regular extended ASCII character set in SoundFont files)
> 2. Convert the strings to UTF-8 when loading and store them as UTF-8 on
> saving.
> 3. Leave the names as is, but convert them in the GUI.
>
> I could see option 1 as probably being the best option, but it wouldn't
> work for characters that aren't part of the limited ISO-8859-1 character
> set.  Ideally this would be prevented on the user input side of things.
>
> Option 2 seems problematic for a number of reasons.  While this option
> would provide the most flexibility in what characters could be stored to
> SoundFont files, there likely would be issues with other programs accessing
> them though (I question whether any UTF-8 encoded SoundFont files can be
> found in the wild - some investigation is in order).  The other issue is
> that converting could result in longer names which might get truncated in
> the limited character width of names in SoundFont files.
>
> Option 3 would lead to the issue where different files types would end up
> having different encodings in the libInstPatch API.  It would be nice to
> present a common interface to libInstPatch for any instrument file format.
>
> At any rate, thought I'd solicit some input from the swami-devel list.
>
> Cheers!
>
> Element
>
>
Oh yeah, for what it's worth, when I delete one of the replacement
characters while editing an instrument name, etc., several of the following
characters are deleted. I expect any work you do in this area will correct
that behaviour, but I wanted to note it now.

As a recent addition to the swami-devel list myself, I'll offer an opinion.
If this is the specification: http://freepats.zenvoid.org/sf2/sfspec24.pdf,
I think storing any unicode (UTF-8 or otherwise) is not a good idea. The
spec speaks of ASCII a good deal, but doesn't seem to know anything about
unicode. It seems to be an old standard from the days when "ASCII" was
"good enough". Of course, "ASCII" is not good enough, and leaves many
questions unanswered. I don't see an allowable character set in the spec,
either. This leaves us asking: are tabs allowed? What about line-feed?
Terminal Bell (0x7)? And extended characters (this is the current question,
I believe) past 128?

I tend to be very restrained when interpreting standards, etc., so I would
vote for option 3. Strings in this spec should be treated as "ASCII". There
is no way to signal to the file interpreter that any other encoding is
present. Of course, what is done with them in the GUI has little to do with
the standard, but UTF-8 seems expedient. You'll also have to deal with a
user inputting, say, checkmark (
http://www.fileformat.info/info/unicode/char/2713/index.htm), then trying
to save it. Perhaps an error earlier (when the user performs the input)
rather than later (at file-save time) would be better.

In case it helps, you can see the "stop list" for jeux 1.4:
http://www.realmac.info/grenade1.htm to make sure you're getting the right
characters.

>From my perspective, you're doing excellent work; thanks!

In Christ,
Aaron Laws

Re: [Swami-devel] Segmentation Fault

[Aaron L. <dar...@gm...>]

On Wed, Jul 6, 2016 at 3:12 AM, Element Green <el...@el...>
wrote:

> Hello Aaron,
>
> Fixed several bugs related to the instrument soloing feature, including:
> - Assertion crash when deleting instrument zone which is currently solo
> - Negative object reference if a non-solo-able instrument is selected
> while in solo mode
>
> Hopefully that should make your life a little easier ;-)  Let me know if
> you dig up any other bugs and thanks for helping track these down!
>
> Cheers.
>
> Element
>
> On Tue, Jul 5, 2016 at 2:58 PM, Element Green <el...@el...
> > wrote:
>
>> Ok, that one I can reproduce..  It looks like it occurred when you
>> deleted a preset zone which was currently in solo mode.  I was not able to
>> get it to crash, if I first unsolo the instrument before deleting it.  I'll
>> look in to this later today.
>>
>> Element
>>
>
Ah, that makes sense! Thanks!

Re: [Swami-devel] Swami-devel Digest, Vol 41, Issue 1, Virtual Pipe Organ

[Aaron L. <dar...@gm...>]

On Tue, Jul 5, 2016 at 10:52 PM, <ra...@hy...> wrote:

> Hi,
>
> With respect to Aaron Laws desire to create a digital "virtual pipe"
> organ,  the package he should probably be working with is GENPO
>
> https://www.hydrophones.com/MAI-Audio/MAI-Audio-Workstation4.html
>
> http://genpo.sourceforge.net/
>
> to control the organ.  Of course, the appropriate SoundFont would be
> created with Swami.  The two tools together can create some awesome
> organs.
> Good luck!
>
> Rich Marschall
>

Thank you for the note. I haven't properly begun the project yet: I haven't
created a key-scanning interface for my organ, but I've been looking at
jorgan, and it looks promising. I don't think I need anything more than a
quite good soundfont (or two or three), and a way to play notes from it. In
other words, I don't have any desire (at this point) to filter the sound;
I'm only looking to amplify it.

I am planning on putting a computer in my organ (or making my organ into a
computer -- whatever way you want to think about it), so both options can
be explored simultaneously. Thanks for the recommendation!

In Christ,

Aaron Laws

[Swami-devel] Character encodings

[Element G. <el...@el...>]

I did some investigation in regards to the invalid UTF-8 string issues.
Examining the names of the instruments in the Jeux14.sf2 SoundFont reveals
that they are encoded as ISO-8859-1 strings (basically the extended ASCII
set).

At this point I am undecided as to the best way to deal with this.  I see a
couple of options:
1. Convert the strings to/from UTF-8 when the SoundFont is loaded/saved
(preserving the regular extended ASCII character set in SoundFont files)
2. Convert the strings to UTF-8 when loading and store them as UTF-8 on
saving.
3. Leave the names as is, but convert them in the GUI.

I could see option 1 as probably being the best option, but it wouldn't
work for characters that aren't part of the limited ISO-8859-1 character
set.  Ideally this would be prevented on the user input side of things.

Option 2 seems problematic for a number of reasons.  While this option
would provide the most flexibility in what characters could be stored to
SoundFont files, there likely would be issues with other programs accessing
them though (I question whether any UTF-8 encoded SoundFont files can be
found in the wild - some investigation is in order).  The other issue is
that converting could result in longer names which might get truncated in
the limited character width of names in SoundFont files.

Option 3 would lead to the issue where different files types would end up
having different encodings in the libInstPatch API.  It would be nice to
present a common interface to libInstPatch for any instrument file format.

At any rate, thought I'd solicit some input from the swami-devel list.

Cheers!

Element

Re: [Swami-devel] Segmentation Fault

[Element G. <el...@el...>]

Hello Aaron,

Fixed several bugs related to the instrument soloing feature, including:
- Assertion crash when deleting instrument zone which is currently solo
- Negative object reference if a non-solo-able instrument is selected while
in solo mode

Hopefully that should make your life a little easier ;-)  Let me know if
you dig up any other bugs and thanks for helping track these down!

Cheers.

Element

On Tue, Jul 5, 2016 at 2:58 PM, Element Green <el...@el...>
wrote:

> Ok, that one I can reproduce..  It looks like it occurred when you deleted
> a preset zone which was currently in solo mode.  I was not able to get it
> to crash, if I first unsolo the instrument before deleting it.  I'll look
> in to this later today.
>
> Element
>
>
>
> On Tue, Jul 5, 2016 at 2:49 PM, Aaron Laws <dar...@gm...> wrote:
>
>> On Tue, Jul 5, 2016 at 4:15 PM, Element Green <
>> el...@el...> wrote:
>>
>>> It looks like debugging may still be disabled since it isn't showing
>>> line numbers.  However, that information is helpful.  Is that backtrace
>>> from the latest git revision on the main branch?  Please double check that
>>> the libraries shown in /usr/local/lib64 look up to date (ls -l
>>> /usr/local/lib64).
>>>
>>> It seems from that backtrace that the crash occurred in relation to a
>>> zone being removed (can't tell if it is a preset or instrument zone).  It
>>> seems it got removed and then the crash occurs in the GtkTree related code,
>>> which is probably still trying to access a deleted item or something.
>>>
>>> I just opened up that SoundFont and went on a deleting spree without ill
>>> effect.  If you could get a general idea of what kinds of operations you
>>> are performing during a session, that might help me to reproduce it.
>>>
>>> It could be there is something happening with library versions or other
>>> weirdness on your system though.  If the backtraces seem fairly
>>> inconsistent this could point more to this possibility.  For example if
>>> libInstPatch and Swami are out of sync, because of duplicate libraries
>>> somewhere or something like that.  If in doubt delete libInstPatch and
>>> Swami from /usr/local and make clean/rebuild libInstPatch and Swami.
>>>
>>> When things get really random with memory corruption issues, I will
>>> sometimes use valgrind (like so: valgrind --tool=memcheck
>>> --trace-children=yes swami).  This has the side effect of slowing the
>>> application quite a bit, but it will often catch the first sign of memory
>>> corruption occurring which is extremely helpful.  I just did this and
>>> didn't find anything real noteworthy until exiting the application, where
>>> some invalid memory reads were occurring.  Probably not related to what you
>>> are experiencing though.
>>>
>>> Best regards,
>>>
>>> Element
>>>
>>
>> I removed, built, and reinstalled libinst and swami from 77ea3e0
>> (currently master). I attempted to remove an instrument from a melodic
>> preset and received the following error with backtrace:
>>
>> **
>> Gtk:ERROR:gtktreestore.c:522:gtk_tree_store_get_path: assertion failed:
>> (G_NODE (iter->user_data)->parent != NULL)
>>
>> Thread 1 "swami" received signal SIGABRT, Aborted.
>> 0x00007ffff64a6295 in raise () from /usr/lib/libc.so.6
>> (gdb) bt
>> #0  0x00007ffff64a6295 in raise () from /usr/lib/libc.so.6
>> #1  0x00007ffff64a76da in abort () from /usr/lib/libc.so.6
>> #2  0x00007ffff6b5f485 in g_assertion_message () from
>> /usr/lib/libglib-2.0.so.0
>> #3  0x00007ffff6b5f51a in g_assertion_message_expr () from
>> /usr/lib/libglib-2.0.so.0
>> #4  0x00007ffff7520c10 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
>> #5  0x00007ffff7522f98 in gtk_tree_store_set_valist () from
>> /usr/lib/libgtk-x11-2.0.so.0
>> #6  0x00007ffff7523054 in gtk_tree_store_set () from
>> /usr/lib/libgtk-x11-2.0.so.0
>> #7  0x00007ffff7bb6f6f in swamigui_tree_store_change (store=0x6b14c0,
>> item=0x105eba0, label=label@entry=0x0, icon=0x7ffff7bc6bf6
>> "swamigui_inst")
>>     at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiTreeStore.c:294
>> #8  0x00007ffff7ba3695 in swamigui_root_update_solo_item (root=root@entry=0x70c000,
>> solo_item=0x0)
>>     at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiRoot.c:1496
>> #9  0x00007ffff7ba381a in swamigui_root_cb_solo_item (root=0x70c000,
>> pspec=<optimized out>, user_data=<optimized out>)
>>     at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiRoot.c:1468
>> #10 0x00007ffff6e0efa5 in g_closure_invoke () from
>> /usr/lib/libgobject-2.0.so.0
>> #11 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
>> #12 0x00007ffff6e29c1c in g_signal_emit_valist () from
>> /usr/lib/libgobject-2.0.so.0
>> #13 0x00007ffff6e29fff in g_signal_emit () from
>> /usr/lib/libgobject-2.0.so.0
>> #14 0x00007ffff6e133d4 in ?? () from /usr/lib/libgobject-2.0.so.0
>> #15 0x00007ffff6e12c76 in ?? () from /usr/lib/libgobject-2.0.so.0
>> #16 0x00007ffff6e17160 in g_object_set_property () from
>> /usr/lib/libgobject-2.0.so.0
>> #17 0x00007ffff7957d21 in control_prop_set_value_method
>> (control=0x6a08e0, event=0xffc780, value=0xffc798)
>>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControlProp.c:492
>> #18 0x00007ffff7954e88 in swami_control_set_event_real (event=0xffc780,
>> control=0x6a08e0)
>>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1539
>> #19 swami_control_set_event (control=control@entry=0x6a08e0,
>> event=event@entry=0xffc780)
>>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1402
>> #20 0x00007ffff7956b7e in swami_control_transmit_value (control=0xacf820,
>> value=<optimized out>)
>>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1670
>> #21 0x00007ffff7957960 in swami_control_prop_cb_notify (object=0xac3c50,
>> pspec=0xad3e70, ctrlprop=0xacf820)
>>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControlProp.c:765
>> #22 0x00007ffff6e0efa5 in g_closure_invoke () from
>> /usr/lib/libgobject-2.0.so.0
>> #23 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
>> #24 0x00007ffff6e29c1c in g_signal_emit_valist () from
>> /usr/lib/libgobject-2.0.so.0
>> #25 0x00007ffff6e29fff in g_signal_emit () from
>> /usr/lib/libgobject-2.0.so.0
>> #26 0x00007ffff6e133d4 in ?? () from /usr/lib/libgobject-2.0.so.0
>> #27 0x00007ffff6e15891 in g_object_notify () from
>> /usr/lib/libgobject-2.0.so.0
>> #28 0x00007ffff7bb30cf in swamigui_tree_update_selection (tree=0xac3c50)
>> at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiTree.c:371
>> #29 0x00007ffff6e0f1d4 in ?? () from /usr/lib/libgobject-2.0.so.0
>> #30 0x00007ffff6e2990d in g_signal_emit_valist () from
>> /usr/lib/libgobject-2.0.so.0
>> #31 0x00007ffff6e2a4ab in g_signal_emit_by_name () from
>> /usr/lib/libgobject-2.0.so.0
>> #32 0x00007ffff752bfd7 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
>> #33 0x00007ffff6e0efa5 in g_closure_invoke () from
>> /usr/lib/libgobject-2.0.so.0
>> #34 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
>> #35 0x00007ffff6e29c1c in g_signal_emit_valist () from
>> /usr/lib/libgobject-2.0.so.0
>> #36 0x00007ffff6e29fff in g_signal_emit () from
>> /usr/lib/libgobject-2.0.so.0
>> #37 0x00007ffff75231c0 in gtk_tree_store_remove () from
>> /usr/lib/libgtk-x11-2.0.so.0
>> #38 0x00007ffff7bb7403 in swamigui_tree_store_remove (store=0x6b14c0,
>> item=0x105eba0)
>>     at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiTreeStore.c:319
>> #39 0x00007ffff7ba3c00 in ctrl_remove_set_func (control=0x710980,
>> event=<optimized out>, value=<optimized out>)
>>     at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiRoot.c:841
>> #40 0x00007ffff7954e88 in swami_control_set_event_real (event=0xf3a580,
>> control=0x710980)
>>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1539
>> #41 swami_control_set_event (control=control@entry=0x710980,
>> event=event@entry=0xf3a580)
>>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1402
>> #42 0x00007ffff79557ee in swami_control_transmit_event (control=0x69f860,
>> event=0xf3a580)
>>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1765
>> #43 0x00007ffff79639db in container_remove_notify (container=<optimized
>> out>, item=0x105eba0, user_data=<optimized out>)
>>     at /home/lawsa/source/swami/swami/src/libswami/libswami.c:223
>> #44 0x00007ffff68407f5 in ipatch_container_remove_notify () from
>> /usr/local/lib64/libinstpatch-1.0.so.0
>> #45 0x00007ffff683f2ab in ipatch_container_remove () from
>> /usr/local/lib64/libinstpatch-1.0.so.0
>> #46 0x00007ffff6864a30 in ipatch_item_item_remove_full () from
>> /usr/local/lib64/libinstpatch-1.0.so.0
>> #47 0x00007ffff689cc12 in ipatch_sf2_zone_item_remove_full () from
>> /usr/local/lib64/libinstpatch-1.0.so.0
>> #48 0x00007ffff6865aba in ipatch_item_real_remove_full () from
>> /usr/local/lib64/libinstpatch-1.0.so.0
>> #49 0x00007ffff68659d6 in ipatch_item_remove () from
>> /usr/local/lib64/libinstpatch-1.0.so.0
>> #50 0x00007ffff7bba3a2 in swamigui_delete_items (item_list=<optimized
>> out>) at /home/lawsa/source/swami/swami/src/swamigui/patch_funcs.c:551
>> #51 0x00007ffff7b93d28 in swamigui_item_menu_callback_activate
>> (mitem=<optimized out>, user_data=0x0)
>>     at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiItemMenu.c:474
>> #52 0x00007ffff6e0efa5 in g_closure_invoke () from
>> /usr/lib/libgobject-2.0.so.0
>> #53 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
>> #54 0x00007ffff6e29c1c in g_signal_emit_valist () from
>> /usr/lib/libgobject-2.0.so.0
>> #55 0x00007ffff6e29fff in g_signal_emit () from
>> /usr/lib/libgobject-2.0.so.0
>> #56 0x00007ffff754f06e in gtk_widget_activate () from
>> /usr/lib/libgtk-x11-2.0.so.0
>> #57 0x00007ffff744a6dd in gtk_menu_shell_activate_item () from
>> /usr/lib/libgtk-x11-2.0.so.0
>> #58 0x00007ffff744aa46 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
>> #59 0x00007ffff743891c in ?? () from /usr/lib/libgtk-x11-2.0.so.0
>> #60 0x00007ffff6e0efa5 in g_closure_invoke () from
>> /usr/lib/libgobject-2.0.so.0
>> #61 0x00007ffff6e213ad in ?? () from /usr/lib/libgobject-2.0.so.0
>> #62 0x00007ffff6e296bf in g_signal_emit_valist () from
>> /usr/lib/libgobject-2.0.so.0
>> #63 0x00007ffff6e29fff in g_signal_emit () from
>> /usr/lib/libgobject-2.0.so.0
>> #64 0x00007ffff75502dc in ?? () from /usr/lib/libgtk-x11-2.0.so.0
>> #65 0x00007ffff74370b4 in gtk_propagate_event () from
>> /usr/lib/libgtk-x11-2.0.so.0
>> #66 0x00007ffff743746b in gtk_main_do_event () from
>> /usr/lib/libgtk-x11-2.0.so.0
>> #67 0x00007ffff70ac3ac in ?? () from /usr/lib/libgdk-x11-2.0.so.0
>> #68 0x00007ffff6b39dd7 in g_main_context_dispatch () from
>> /usr/lib/libglib-2.0.so.0
>> #69 0x00007ffff6b3a040 in ?? () from /usr/lib/libglib-2.0.so.0
>> #70 0x00007ffff6b3a362 in g_main_loop_run () from
>> /usr/lib/libglib-2.0.so.0
>> #71 0x00007ffff74364e7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
>> #72 0x0000000000401409 in main (argc=<optimized out>, argv=<optimized
>> out>) at /home/lawsa/source/swami/swami/src/swamigui/main.c:179
>>
>>
>> Apparently I compiled swami with -g, but not libinst. Would it help to
>> have libinst file names and line numbers, too?
>>
>> It's not just deleting that causes the problem, but specifically (for
>> me), deleting instruments from presets. I'm not impressed with the jeux 1.4
>> font combining instruments to create new melodic presets. For instance, the
>> first melodic preset is Montre 8; fine. Then Prestant 4, then Doublette 2;
>> all fine. Then the next is "Montre 8 Prestant 4". I'm fully capable of
>> combining them on my own, so I'm trying to trim out some of this fat (and
>> there is a lot).
>>
>> This includes removing lots of instruments from some of these presets.
>> For instance, on preset 000-003, I delete Montre and Prestant and rename
>> the preset "Pan pipes". Often when deleting those two principal stops,
>> that's where the program crashes...about 1 out of 10 times? Of course,
>> between doing this, I'm listening to the melodic preset and the individual
>> instruments (toggle solo) several times to decide if there's something I'm
>> missing by trimming the preset.
>>
>> I hope it helps!
>>
>> In Christ,
>> Aaron Laws
>>
>
>

Re: [Swami-devel] Swami-devel Digest, Vol 41, Issue 1, Virtual Pipe Organ

[<ra...@hy...>]

Hi,

With respect to Aaron Laws desire to create a digital "virtual pipe"
organ,  the package he should probably be working with is GENPO

https://www.hydrophones.com/MAI-Audio/MAI-Audio-Workstation4.html

http://genpo.sourceforge.net/

to control the organ.  Of course, the appropriate SoundFont would be
created with Swami.  The two tools together can create some awesome
organs.
Good luck!

Rich Marschall


> Send Swami-devel mailing list submissions to
> 	swa...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/swami-devel
> or, via email, send a message with subject or body 'help' to
> 	swa...@li...
>
> You can reach the person managing the list at
> 	swa...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Swami-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: Difficulty Installing (Aaron Laws)
>    2. Segmentation Fault (Aaron Laws)
>    3. Re: Segmentation Fault (Element Green)
>    4. Re: Segmentation Fault (Aaron Laws)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 23 Jun 2016 17:03:04 -0400
> From: Aaron Laws <dar...@gm...>
> Subject: Re: [Swami-devel] Difficulty Installing
> To: Element Green <el...@el...>
> Cc: swami-devel <swa...@li...>
> Message-ID:
> 	<CAD...@ma...>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, Jun 23, 2016 at 3:20 PM, Element Green
> <el...@el...>
> wrote:
>
>> Hmm, I'll look into why version.h isn't being installed.  I'm often
>> running the application from within the source tree, so its easy to
>> overlook these things sometimes.
>>
>> Yeah, Swami predates Polyphone by a long time!  I've only in the past
>> few
>> years seen Polyphone on the scene and haven't actually tried it.
>>
>> Swami is nice, but needs some work to make it complete.  I'll be turning
>> my attention back on it soon again.  I have some other things I want to
>> implement too which will make it a fun tool to use for music composition
>> (instrument library indexing support, more work on virtual banks for
>> easily
>> combining instrument files into a custom MIDI map and assigning
>> percussion
>> instruments to pads, improved global session modulators for defining
>> controls for all instruments loaded, undo/redo support, etc).
>>
>> Cheers,
>>
>> Element
>>
>
> My interest in the project isn't to create soundfont files. I just got an
> electric Allen organ (60s?), and I would like to gut it and make it into a
> MIDI organ. There are some excellent free soundfonts for various organs
> available. I am writing an application to run in my organ against
> fluidsynth, and I was running up against problems. I wanted to look into
> the soundfont file I was using (jeux 1.4
> http://www.realmac.info/cab123.mp3)
> to get an idea of what's in there, and how the file is organized.
>
> On a separate note, does anyone happen to know how to play more than one
> note at a time in fluidsynth? I think I could do it if I put each "stop"
> on
> a different channel, but there aren't many channels to go round! My goal
> is
> that a note_on midi message will start 2 or more sounds (say, Gedekt 8'
> and
> flute 4').
>
> Thanks again!
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 2
> Date: Tue, 5 Jul 2016 14:52:06 -0400
> From: Aaron Laws <dar...@gm...>
> Subject: [Swami-devel] Segmentation Fault
> To: swami-devel <swa...@li...>
> Message-ID:
> 	<CADu-kvfrXB=1rO...@ma...>
> Content-Type: text/plain; charset="utf-8"
>
> I just started using swami to create a new sound font based on an existing
> one. I experience segmentation faults quite often. The font that I'm
> editing is Jeux 1.4 (http://www.realmac.info/download.htm) which seems to
> have some bogus characters. O-umlaut and other characters with accents
> don't show up properly. I haven't investigated closely, but it seems like
> they might be encoded as UTF-16? Anyway, swami complained quite a bit
> about
> "invalid UTF-8 strings", and I removed all the bogus characters I can see.
>
> That didn't stop the crashing, however. It usually happens when I delete
> (e.g.) an instrument from a melodic preset. The error is:
>
> Gtk:ERROR:gtktreestore.c:522:gtk_tree_store_get_path: assertion failed:
> (G_NODE (iter->user_data)->parent != NULL)
> Aborted (core dumped)
>
> The crashes are frequent enough that I'm saving very often now (so,
> perhaps
> a good thing after all). Happily, swami starts back up pretty quickly.
> I'll
> keep an eye on it and see if I ever get a different message.
>
> Also, please let me know if there's a startup parameter or something else
> I
> can do to get more output (stack track?), etc.
>
> In Christ,
> Aaron Laws
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 3
> Date: Tue, 5 Jul 2016 13:11:56 -0600
> From: Element Green <el...@el...>
> Subject: Re: [Swami-devel] Segmentation Fault
> To: Aaron Laws <dar...@gm...>
> Cc: swami-devel <swa...@li...>
> Message-ID:
> 	<CAJ...@ma...>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Aaron,
>
> I also have the SoundFont you mentioned, but I don't believe I have
> experienced a crash with it particularly.
>
> What version of Swami are you using?  Is it from a binary package in your
> distribution or from source code?  I have recently been doing a lot of
> development (the past week), after many years of inactivity.  Perhaps you
> are using the bleeding edge git master branch which is currently in heavy
> development?  If you aren't, then it would be nice to see if you
> experience
> crashes with it as well, since it may actually be in better shape that
> what
> you are currently using.
>
> I just loaded up that SoundFont and also see that it complains about
> invalid UTF-8 strings.  It would be nice to handle this properly.  I don't
> seem to remember anything in the SoundFont spec about character encodings,
> so that may mean there are a lot of variations in the wild.  Could be a
> mess.  But at least allowing some way to select the character encoding or
> try and detect it might be nice.
>
> As far as debugging things..  You'll probably want to build Swami from
> source with debugging enabled.  Otherwise backtraces will be less than
> useful.  This isn't enabled by default.  Let me know if you want to try
> this and need any assistance.  I suggest using cmake to build it rather
> than autoconf (I'm considering dropping autoconf build support).  You
> would
> then start up swami in a terminal like:
> gdb swami [ENTER]
>
> Then type 'r' and ENTER to run the program.  Do stuff, wait for it to
> crash
> which will show the GDB prompt again and then do:
> bt [ENTER]
>
> That should give you a backtrace, that you can copy/paste.
>
> Best regards,
>
> Element
>
> On Tue, Jul 5, 2016 at 12:52 PM, Aaron Laws <dar...@gm...> wrote:
>
>> I just started using swami to create a new sound font based on an
>> existing
>> one. I experience segmentation faults quite often. The font that I'm
>> editing is Jeux 1.4 (http://www.realmac.info/download.htm) which seems
>> to
>> have some bogus characters. O-umlaut and other characters with accents
>> don't show up properly. I haven't investigated closely, but it seems
>> like
>> they might be encoded as UTF-16? Anyway, swami complained quite a bit
>> about
>> "invalid UTF-8 strings", and I removed all the bogus characters I can
>> see.
>>
>> That didn't stop the crashing, however. It usually happens when I delete
>> (e.g.) an instrument from a melodic preset. The error is:
>>
>> Gtk:ERROR:gtktreestore.c:522:gtk_tree_store_get_path: assertion failed:
>> (G_NODE (iter->user_data)->parent != NULL)
>> Aborted (core dumped)
>>
>> The crashes are frequent enough that I'm saving very often now (so,
>> perhaps a good thing after all). Happily, swami starts back up pretty
>> quickly. I'll keep an eye on it and see if I ever get a different
>> message.
>>
>> Also, please let me know if there's a startup parameter or something
>> else
>> I can do to get more output (stack track?), etc.
>>
>> In Christ,
>> Aaron Laws
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> _______________________________________________
>> Swami-devel mailing list
>> Swa...@li...
>> https://lists.sourceforge.net/lists/listinfo/swami-devel
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 4
> Date: Tue, 5 Jul 2016 15:20:56 -0400
> From: Aaron Laws <dar...@gm...>
> Subject: Re: [Swami-devel] Segmentation Fault
> To: swami-devel <swa...@li...>
> Message-ID:
> 	<CAD...@ma...>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, Jul 5, 2016 at 2:52 PM, Aaron Laws <dar...@gm...> wrote:
>
>> I just started using swami to create a new sound font based on an
>> existing
>> one. I experience segmentation faults quite often. The font that I'm
>> editing is Jeux 1.4 (http://www.realmac.info/download.htm) which seems
>> to
>> have some bogus characters. O-umlaut and other characters with accents
>> don't show up properly. I haven't investigated closely, but it seems
>> like
>> they might be encoded as UTF-16? Anyway, swami complained quite a bit
>> about
>> "invalid UTF-8 strings", and I removed all the bogus characters I can
>> see.
>>
>> That didn't stop the crashing, however. It usually happens when I delete
>> (e.g.) an instrument from a melodic preset. The error is:
>>
>> Gtk:ERROR:gtktreestore.c:522:gtk_tree_store_get_path: assertion failed:
>> (G_NODE (iter->user_data)->parent != NULL)
>> Aborted (core dumped)
>>
>> The crashes are frequent enough that I'm saving very often now (so,
>> perhaps a good thing after all). Happily, swami starts back up pretty
>> quickly. I'll keep an eye on it and see if I ever get a different
>> message.
>>
>> Also, please let me know if there's a startup parameter or something
>> else
>> I can do to get more output (stack track?), etc.
>>
>> In Christ,
>> Aaron Laws
>>
>>
>
> Just now, again, when trying to remove 4 or so non-contiguous instruments
> from a melodic preset, I got:
>
>  ** (swami:31545): CRITICAL **: ipatch_unit_convert: assertion 'src_info
> !=
> NULL' failed
> Segmentation fault (core dumped)
>
> the swami:31545 message was posted several times, and not just when the
> failure happened, but over the course of my work.
>
> It's worth mentioning that I restarted swami, and did the exact same
> thing,
> but it worked this time.
>
>
> A little later, I get:
> (swami:32394): GnomeCanvas-CRITICAL **: gnome_canvas_item_lower_to_bottom:
> assertion 'GNOME_IS_CANVAS_ITEM (item)' failed
> (swami:32394): GLib-GObject-CRITICAL **: g_object_set: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:32394): GLib-GObject-WARNING **: invalid unclassed pointer in cast
> to 'GtkObject'
> (swami:32394): Gtk-CRITICAL **: IA__gtk_object_destroy: assertion
> 'GTK_IS_OBJECT (object)' failed
> (swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> Segmentation fault (core dumped)
>
> A couple minutes later:
>
> (swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:1432): GLib-GObject-WARNING **: instance of invalid
> non-instantiatable type '<invalid>'
> (swami:1432): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion
> 'G_TYPE_CHECK_INSTANCE (instance)' failed
> (swami:1432): GLib-GObject-WARNING **: instance of invalid
> non-instantiatable type '<invalid>'
> (swami:1432): GLib-GObject-CRITICAL **: g_signal_handlers_destroy:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> (swami:1432): GLib-GObject-WARNING **: instance of invalid
> non-instantiatable type '<invalid>'
> (swami:1432): GLib-GObject-CRITICAL **: g_signal_handlers_destroy:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> (swami:1432): GnomeCanvas-CRITICAL **: gnome_canvas_item_raise_to_top:
> assertion 'GNOME_IS_CANVAS_ITEM (item)' failed
> (swami:1432): GLib-GObject-CRITICAL **: g_object_set: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:1432): GnomeCanvas-CRITICAL **: gnome_canvas_item_lower_to_bottom:
> assertion 'GNOME_IS_CANVAS_ITEM (item)' failed
> (swami:1432): GLib-GObject-CRITICAL **: g_object_set: assertion
> 'G_IS_OBJECT (object)' failed
> **
> Gtk:ERROR:gtktreestore.c:522:gtk_tree_store_get_path: assertion failed:
> (G_NODE (iter->user_data)->parent != NULL)
> Aborted (core dumped)
>
>
> I see your response already. I just checked, and I made from cmake. I'll
> run from gdb and see what I can see. I'm on commit d27e8ed. I just ran git
> fetch, and I see that you've been committing a lot lately!
>
> Should I try the stable branch?
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
>
> ------------------------------
>
> _______________________________________________
> Swami-devel mailing list
> Swa...@li...
> https://lists.sourceforge.net/lists/listinfo/swami-devel
>
>
> End of Swami-devel Digest, Vol 41, Issue 1
> ******************************************
>

Re: [Swami-devel] Segmentation Fault

[Element G. <el...@el...>]

Ok, that one I can reproduce..  It looks like it occurred when you deleted
a preset zone which was currently in solo mode.  I was not able to get it
to crash, if I first unsolo the instrument before deleting it.  I'll look
in to this later today.

Element


On Tue, Jul 5, 2016 at 2:49 PM, Aaron Laws <dar...@gm...> wrote:

> On Tue, Jul 5, 2016 at 4:15 PM, Element Green <el...@el...
> > wrote:
>
>> It looks like debugging may still be disabled since it isn't showing line
>> numbers.  However, that information is helpful.  Is that backtrace from the
>> latest git revision on the main branch?  Please double check that the
>> libraries shown in /usr/local/lib64 look up to date (ls -l
>> /usr/local/lib64).
>>
>> It seems from that backtrace that the crash occurred in relation to a
>> zone being removed (can't tell if it is a preset or instrument zone).  It
>> seems it got removed and then the crash occurs in the GtkTree related code,
>> which is probably still trying to access a deleted item or something.
>>
>> I just opened up that SoundFont and went on a deleting spree without ill
>> effect.  If you could get a general idea of what kinds of operations you
>> are performing during a session, that might help me to reproduce it.
>>
>> It could be there is something happening with library versions or other
>> weirdness on your system though.  If the backtraces seem fairly
>> inconsistent this could point more to this possibility.  For example if
>> libInstPatch and Swami are out of sync, because of duplicate libraries
>> somewhere or something like that.  If in doubt delete libInstPatch and
>> Swami from /usr/local and make clean/rebuild libInstPatch and Swami.
>>
>> When things get really random with memory corruption issues, I will
>> sometimes use valgrind (like so: valgrind --tool=memcheck
>> --trace-children=yes swami).  This has the side effect of slowing the
>> application quite a bit, but it will often catch the first sign of memory
>> corruption occurring which is extremely helpful.  I just did this and
>> didn't find anything real noteworthy until exiting the application, where
>> some invalid memory reads were occurring.  Probably not related to what you
>> are experiencing though.
>>
>> Best regards,
>>
>> Element
>>
>
> I removed, built, and reinstalled libinst and swami from 77ea3e0
> (currently master). I attempted to remove an instrument from a melodic
> preset and received the following error with backtrace:
>
> **
> Gtk:ERROR:gtktreestore.c:522:gtk_tree_store_get_path: assertion failed:
> (G_NODE (iter->user_data)->parent != NULL)
>
> Thread 1 "swami" received signal SIGABRT, Aborted.
> 0x00007ffff64a6295 in raise () from /usr/lib/libc.so.6
> (gdb) bt
> #0  0x00007ffff64a6295 in raise () from /usr/lib/libc.so.6
> #1  0x00007ffff64a76da in abort () from /usr/lib/libc.so.6
> #2  0x00007ffff6b5f485 in g_assertion_message () from
> /usr/lib/libglib-2.0.so.0
> #3  0x00007ffff6b5f51a in g_assertion_message_expr () from
> /usr/lib/libglib-2.0.so.0
> #4  0x00007ffff7520c10 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #5  0x00007ffff7522f98 in gtk_tree_store_set_valist () from
> /usr/lib/libgtk-x11-2.0.so.0
> #6  0x00007ffff7523054 in gtk_tree_store_set () from
> /usr/lib/libgtk-x11-2.0.so.0
> #7  0x00007ffff7bb6f6f in swamigui_tree_store_change (store=0x6b14c0,
> item=0x105eba0, label=label@entry=0x0, icon=0x7ffff7bc6bf6
> "swamigui_inst")
>     at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiTreeStore.c:294
> #8  0x00007ffff7ba3695 in swamigui_root_update_solo_item (root=root@entry=0x70c000,
> solo_item=0x0)
>     at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiRoot.c:1496
> #9  0x00007ffff7ba381a in swamigui_root_cb_solo_item (root=0x70c000,
> pspec=<optimized out>, user_data=<optimized out>)
>     at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiRoot.c:1468
> #10 0x00007ffff6e0efa5 in g_closure_invoke () from
> /usr/lib/libgobject-2.0.so.0
> #11 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
> #12 0x00007ffff6e29c1c in g_signal_emit_valist () from
> /usr/lib/libgobject-2.0.so.0
> #13 0x00007ffff6e29fff in g_signal_emit () from
> /usr/lib/libgobject-2.0.so.0
> #14 0x00007ffff6e133d4 in ?? () from /usr/lib/libgobject-2.0.so.0
> #15 0x00007ffff6e12c76 in ?? () from /usr/lib/libgobject-2.0.so.0
> #16 0x00007ffff6e17160 in g_object_set_property () from
> /usr/lib/libgobject-2.0.so.0
> #17 0x00007ffff7957d21 in control_prop_set_value_method (control=0x6a08e0,
> event=0xffc780, value=0xffc798)
>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControlProp.c:492
> #18 0x00007ffff7954e88 in swami_control_set_event_real (event=0xffc780,
> control=0x6a08e0)
>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1539
> #19 swami_control_set_event (control=control@entry=0x6a08e0,
> event=event@entry=0xffc780)
>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1402
> #20 0x00007ffff7956b7e in swami_control_transmit_value (control=0xacf820,
> value=<optimized out>)
>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1670
> #21 0x00007ffff7957960 in swami_control_prop_cb_notify (object=0xac3c50,
> pspec=0xad3e70, ctrlprop=0xacf820)
>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControlProp.c:765
> #22 0x00007ffff6e0efa5 in g_closure_invoke () from
> /usr/lib/libgobject-2.0.so.0
> #23 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
> #24 0x00007ffff6e29c1c in g_signal_emit_valist () from
> /usr/lib/libgobject-2.0.so.0
> #25 0x00007ffff6e29fff in g_signal_emit () from
> /usr/lib/libgobject-2.0.so.0
> #26 0x00007ffff6e133d4 in ?? () from /usr/lib/libgobject-2.0.so.0
> #27 0x00007ffff6e15891 in g_object_notify () from
> /usr/lib/libgobject-2.0.so.0
> #28 0x00007ffff7bb30cf in swamigui_tree_update_selection (tree=0xac3c50)
> at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiTree.c:371
> #29 0x00007ffff6e0f1d4 in ?? () from /usr/lib/libgobject-2.0.so.0
> #30 0x00007ffff6e2990d in g_signal_emit_valist () from
> /usr/lib/libgobject-2.0.so.0
> #31 0x00007ffff6e2a4ab in g_signal_emit_by_name () from
> /usr/lib/libgobject-2.0.so.0
> #32 0x00007ffff752bfd7 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #33 0x00007ffff6e0efa5 in g_closure_invoke () from
> /usr/lib/libgobject-2.0.so.0
> #34 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
> #35 0x00007ffff6e29c1c in g_signal_emit_valist () from
> /usr/lib/libgobject-2.0.so.0
> #36 0x00007ffff6e29fff in g_signal_emit () from
> /usr/lib/libgobject-2.0.so.0
> #37 0x00007ffff75231c0 in gtk_tree_store_remove () from
> /usr/lib/libgtk-x11-2.0.so.0
> #38 0x00007ffff7bb7403 in swamigui_tree_store_remove (store=0x6b14c0,
> item=0x105eba0)
>     at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiTreeStore.c:319
> #39 0x00007ffff7ba3c00 in ctrl_remove_set_func (control=0x710980,
> event=<optimized out>, value=<optimized out>)
>     at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiRoot.c:841
> #40 0x00007ffff7954e88 in swami_control_set_event_real (event=0xf3a580,
> control=0x710980)
>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1539
> #41 swami_control_set_event (control=control@entry=0x710980,
> event=event@entry=0xf3a580)
>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1402
> #42 0x00007ffff79557ee in swami_control_transmit_event (control=0x69f860,
> event=0xf3a580)
>     at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1765
> #43 0x00007ffff79639db in container_remove_notify (container=<optimized
> out>, item=0x105eba0, user_data=<optimized out>)
>     at /home/lawsa/source/swami/swami/src/libswami/libswami.c:223
> #44 0x00007ffff68407f5 in ipatch_container_remove_notify () from
> /usr/local/lib64/libinstpatch-1.0.so.0
> #45 0x00007ffff683f2ab in ipatch_container_remove () from
> /usr/local/lib64/libinstpatch-1.0.so.0
> #46 0x00007ffff6864a30 in ipatch_item_item_remove_full () from
> /usr/local/lib64/libinstpatch-1.0.so.0
> #47 0x00007ffff689cc12 in ipatch_sf2_zone_item_remove_full () from
> /usr/local/lib64/libinstpatch-1.0.so.0
> #48 0x00007ffff6865aba in ipatch_item_real_remove_full () from
> /usr/local/lib64/libinstpatch-1.0.so.0
> #49 0x00007ffff68659d6 in ipatch_item_remove () from
> /usr/local/lib64/libinstpatch-1.0.so.0
> #50 0x00007ffff7bba3a2 in swamigui_delete_items (item_list=<optimized
> out>) at /home/lawsa/source/swami/swami/src/swamigui/patch_funcs.c:551
> #51 0x00007ffff7b93d28 in swamigui_item_menu_callback_activate
> (mitem=<optimized out>, user_data=0x0)
>     at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiItemMenu.c:474
> #52 0x00007ffff6e0efa5 in g_closure_invoke () from
> /usr/lib/libgobject-2.0.so.0
> #53 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
> #54 0x00007ffff6e29c1c in g_signal_emit_valist () from
> /usr/lib/libgobject-2.0.so.0
> #55 0x00007ffff6e29fff in g_signal_emit () from
> /usr/lib/libgobject-2.0.so.0
> #56 0x00007ffff754f06e in gtk_widget_activate () from
> /usr/lib/libgtk-x11-2.0.so.0
> #57 0x00007ffff744a6dd in gtk_menu_shell_activate_item () from
> /usr/lib/libgtk-x11-2.0.so.0
> #58 0x00007ffff744aa46 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #59 0x00007ffff743891c in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #60 0x00007ffff6e0efa5 in g_closure_invoke () from
> /usr/lib/libgobject-2.0.so.0
> #61 0x00007ffff6e213ad in ?? () from /usr/lib/libgobject-2.0.so.0
> #62 0x00007ffff6e296bf in g_signal_emit_valist () from
> /usr/lib/libgobject-2.0.so.0
> #63 0x00007ffff6e29fff in g_signal_emit () from
> /usr/lib/libgobject-2.0.so.0
> #64 0x00007ffff75502dc in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #65 0x00007ffff74370b4 in gtk_propagate_event () from
> /usr/lib/libgtk-x11-2.0.so.0
> #66 0x00007ffff743746b in gtk_main_do_event () from
> /usr/lib/libgtk-x11-2.0.so.0
> #67 0x00007ffff70ac3ac in ?? () from /usr/lib/libgdk-x11-2.0.so.0
> #68 0x00007ffff6b39dd7 in g_main_context_dispatch () from
> /usr/lib/libglib-2.0.so.0
> #69 0x00007ffff6b3a040 in ?? () from /usr/lib/libglib-2.0.so.0
> #70 0x00007ffff6b3a362 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
> #71 0x00007ffff74364e7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
> #72 0x0000000000401409 in main (argc=<optimized out>, argv=<optimized
> out>) at /home/lawsa/source/swami/swami/src/swamigui/main.c:179
>
>
> Apparently I compiled swami with -g, but not libinst. Would it help to
> have libinst file names and line numbers, too?
>
> It's not just deleting that causes the problem, but specifically (for me),
> deleting instruments from presets. I'm not impressed with the jeux 1.4 font
> combining instruments to create new melodic presets. For instance, the
> first melodic preset is Montre 8; fine. Then Prestant 4, then Doublette 2;
> all fine. Then the next is "Montre 8 Prestant 4". I'm fully capable of
> combining them on my own, so I'm trying to trim out some of this fat (and
> there is a lot).
>
> This includes removing lots of instruments from some of these presets. For
> instance, on preset 000-003, I delete Montre and Prestant and rename the
> preset "Pan pipes". Often when deleting those two principal stops, that's
> where the program crashes...about 1 out of 10 times? Of course, between
> doing this, I'm listening to the melodic preset and the individual
> instruments (toggle solo) several times to decide if there's something I'm
> missing by trimming the preset.
>
> I hope it helps!
>
> In Christ,
> Aaron Laws
>

Re: [Swami-devel] Segmentation Fault

[Aaron L. <dar...@gm...>]

On Tue, Jul 5, 2016 at 4:15 PM, Element Green <el...@el...>
wrote:

> It looks like debugging may still be disabled since it isn't showing line
> numbers.  However, that information is helpful.  Is that backtrace from the
> latest git revision on the main branch?  Please double check that the
> libraries shown in /usr/local/lib64 look up to date (ls -l
> /usr/local/lib64).
>
> It seems from that backtrace that the crash occurred in relation to a zone
> being removed (can't tell if it is a preset or instrument zone).  It seems
> it got removed and then the crash occurs in the GtkTree related code, which
> is probably still trying to access a deleted item or something.
>
> I just opened up that SoundFont and went on a deleting spree without ill
> effect.  If you could get a general idea of what kinds of operations you
> are performing during a session, that might help me to reproduce it.
>
> It could be there is something happening with library versions or other
> weirdness on your system though.  If the backtraces seem fairly
> inconsistent this could point more to this possibility.  For example if
> libInstPatch and Swami are out of sync, because of duplicate libraries
> somewhere or something like that.  If in doubt delete libInstPatch and
> Swami from /usr/local and make clean/rebuild libInstPatch and Swami.
>
> When things get really random with memory corruption issues, I will
> sometimes use valgrind (like so: valgrind --tool=memcheck
> --trace-children=yes swami).  This has the side effect of slowing the
> application quite a bit, but it will often catch the first sign of memory
> corruption occurring which is extremely helpful.  I just did this and
> didn't find anything real noteworthy until exiting the application, where
> some invalid memory reads were occurring.  Probably not related to what you
> are experiencing though.
>
> Best regards,
>
> Element
>

I removed, built, and reinstalled libinst and swami from 77ea3e0 (currently
master). I attempted to remove an instrument from a melodic preset and
received the following error with backtrace:

**
Gtk:ERROR:gtktreestore.c:522:gtk_tree_store_get_path: assertion failed:
(G_NODE (iter->user_data)->parent != NULL)

Thread 1 "swami" received signal SIGABRT, Aborted.
0x00007ffff64a6295 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff64a6295 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff64a76da in abort () from /usr/lib/libc.so.6
#2  0x00007ffff6b5f485 in g_assertion_message () from
/usr/lib/libglib-2.0.so.0
#3  0x00007ffff6b5f51a in g_assertion_message_expr () from
/usr/lib/libglib-2.0.so.0
#4  0x00007ffff7520c10 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#5  0x00007ffff7522f98 in gtk_tree_store_set_valist () from
/usr/lib/libgtk-x11-2.0.so.0
#6  0x00007ffff7523054 in gtk_tree_store_set () from
/usr/lib/libgtk-x11-2.0.so.0
#7  0x00007ffff7bb6f6f in swamigui_tree_store_change (store=0x6b14c0,
item=0x105eba0, label=label@entry=0x0, icon=0x7ffff7bc6bf6 "swamigui_inst")
    at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiTreeStore.c:294
#8  0x00007ffff7ba3695 in swamigui_root_update_solo_item
(root=root@entry=0x70c000,
solo_item=0x0)
    at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiRoot.c:1496
#9  0x00007ffff7ba381a in swamigui_root_cb_solo_item (root=0x70c000,
pspec=<optimized out>, user_data=<optimized out>)
    at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiRoot.c:1468
#10 0x00007ffff6e0efa5 in g_closure_invoke () from
/usr/lib/libgobject-2.0.so.0
#11 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
#12 0x00007ffff6e29c1c in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#13 0x00007ffff6e29fff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#14 0x00007ffff6e133d4 in ?? () from /usr/lib/libgobject-2.0.so.0
#15 0x00007ffff6e12c76 in ?? () from /usr/lib/libgobject-2.0.so.0
#16 0x00007ffff6e17160 in g_object_set_property () from
/usr/lib/libgobject-2.0.so.0
#17 0x00007ffff7957d21 in control_prop_set_value_method (control=0x6a08e0,
event=0xffc780, value=0xffc798)
    at /home/lawsa/source/swami/swami/src/libswami/SwamiControlProp.c:492
#18 0x00007ffff7954e88 in swami_control_set_event_real (event=0xffc780,
control=0x6a08e0)
    at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1539
#19 swami_control_set_event (control=control@entry=0x6a08e0,
event=event@entry=0xffc780)
    at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1402
#20 0x00007ffff7956b7e in swami_control_transmit_value (control=0xacf820,
value=<optimized out>)
    at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1670
#21 0x00007ffff7957960 in swami_control_prop_cb_notify (object=0xac3c50,
pspec=0xad3e70, ctrlprop=0xacf820)
    at /home/lawsa/source/swami/swami/src/libswami/SwamiControlProp.c:765
#22 0x00007ffff6e0efa5 in g_closure_invoke () from
/usr/lib/libgobject-2.0.so.0
#23 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
#24 0x00007ffff6e29c1c in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#25 0x00007ffff6e29fff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#26 0x00007ffff6e133d4 in ?? () from /usr/lib/libgobject-2.0.so.0
#27 0x00007ffff6e15891 in g_object_notify () from
/usr/lib/libgobject-2.0.so.0
#28 0x00007ffff7bb30cf in swamigui_tree_update_selection (tree=0xac3c50) at
/home/lawsa/source/swami/swami/src/swamigui/SwamiguiTree.c:371
#29 0x00007ffff6e0f1d4 in ?? () from /usr/lib/libgobject-2.0.so.0
#30 0x00007ffff6e2990d in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#31 0x00007ffff6e2a4ab in g_signal_emit_by_name () from
/usr/lib/libgobject-2.0.so.0
#32 0x00007ffff752bfd7 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#33 0x00007ffff6e0efa5 in g_closure_invoke () from
/usr/lib/libgobject-2.0.so.0
#34 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
#35 0x00007ffff6e29c1c in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#36 0x00007ffff6e29fff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#37 0x00007ffff75231c0 in gtk_tree_store_remove () from
/usr/lib/libgtk-x11-2.0.so.0
#38 0x00007ffff7bb7403 in swamigui_tree_store_remove (store=0x6b14c0,
item=0x105eba0)
    at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiTreeStore.c:319
#39 0x00007ffff7ba3c00 in ctrl_remove_set_func (control=0x710980,
event=<optimized out>, value=<optimized out>)
    at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiRoot.c:841
#40 0x00007ffff7954e88 in swami_control_set_event_real (event=0xf3a580,
control=0x710980)
    at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1539
#41 swami_control_set_event (control=control@entry=0x710980,
event=event@entry=0xf3a580)
    at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1402
#42 0x00007ffff79557ee in swami_control_transmit_event (control=0x69f860,
event=0xf3a580)
    at /home/lawsa/source/swami/swami/src/libswami/SwamiControl.c:1765
#43 0x00007ffff79639db in container_remove_notify (container=<optimized
out>, item=0x105eba0, user_data=<optimized out>)
    at /home/lawsa/source/swami/swami/src/libswami/libswami.c:223
#44 0x00007ffff68407f5 in ipatch_container_remove_notify () from
/usr/local/lib64/libinstpatch-1.0.so.0
#45 0x00007ffff683f2ab in ipatch_container_remove () from
/usr/local/lib64/libinstpatch-1.0.so.0
#46 0x00007ffff6864a30 in ipatch_item_item_remove_full () from
/usr/local/lib64/libinstpatch-1.0.so.0
#47 0x00007ffff689cc12 in ipatch_sf2_zone_item_remove_full () from
/usr/local/lib64/libinstpatch-1.0.so.0
#48 0x00007ffff6865aba in ipatch_item_real_remove_full () from
/usr/local/lib64/libinstpatch-1.0.so.0
#49 0x00007ffff68659d6 in ipatch_item_remove () from
/usr/local/lib64/libinstpatch-1.0.so.0
#50 0x00007ffff7bba3a2 in swamigui_delete_items (item_list=<optimized out>)
at /home/lawsa/source/swami/swami/src/swamigui/patch_funcs.c:551
#51 0x00007ffff7b93d28 in swamigui_item_menu_callback_activate
(mitem=<optimized out>, user_data=0x0)
    at /home/lawsa/source/swami/swami/src/swamigui/SwamiguiItemMenu.c:474
#52 0x00007ffff6e0efa5 in g_closure_invoke () from
/usr/lib/libgobject-2.0.so.0
#53 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
#54 0x00007ffff6e29c1c in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#55 0x00007ffff6e29fff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#56 0x00007ffff754f06e in gtk_widget_activate () from
/usr/lib/libgtk-x11-2.0.so.0
#57 0x00007ffff744a6dd in gtk_menu_shell_activate_item () from
/usr/lib/libgtk-x11-2.0.so.0
#58 0x00007ffff744aa46 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#59 0x00007ffff743891c in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#60 0x00007ffff6e0efa5 in g_closure_invoke () from
/usr/lib/libgobject-2.0.so.0
#61 0x00007ffff6e213ad in ?? () from /usr/lib/libgobject-2.0.so.0
#62 0x00007ffff6e296bf in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#63 0x00007ffff6e29fff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#64 0x00007ffff75502dc in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#65 0x00007ffff74370b4 in gtk_propagate_event () from
/usr/lib/libgtk-x11-2.0.so.0
#66 0x00007ffff743746b in gtk_main_do_event () from
/usr/lib/libgtk-x11-2.0.so.0
#67 0x00007ffff70ac3ac in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#68 0x00007ffff6b39dd7 in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#69 0x00007ffff6b3a040 in ?? () from /usr/lib/libglib-2.0.so.0
#70 0x00007ffff6b3a362 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#71 0x00007ffff74364e7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#72 0x0000000000401409 in main (argc=<optimized out>, argv=<optimized out>)
at /home/lawsa/source/swami/swami/src/swamigui/main.c:179


Apparently I compiled swami with -g, but not libinst. Would it help to have
libinst file names and line numbers, too?

It's not just deleting that causes the problem, but specifically (for me),
deleting instruments from presets. I'm not impressed with the jeux 1.4 font
combining instruments to create new melodic presets. For instance, the
first melodic preset is Montre 8; fine. Then Prestant 4, then Doublette 2;
all fine. Then the next is "Montre 8 Prestant 4". I'm fully capable of
combining them on my own, so I'm trying to trim out some of this fat (and
there is a lot).

This includes removing lots of instruments from some of these presets. For
instance, on preset 000-003, I delete Montre and Prestant and rename the
preset "Pan pipes". Often when deleting those two principal stops, that's
where the program crashes...about 1 out of 10 times? Of course, between
doing this, I'm listening to the melodic preset and the individual
instruments (toggle solo) several times to decide if there's something I'm
missing by trimming the preset.

I hope it helps!

In Christ,
Aaron Laws

Re: [Swami-devel] Segmentation Fault

[Element G. <el...@el...>]

It looks like debugging may still be disabled since it isn't showing line
numbers.  However, that information is helpful.  Is that backtrace from the
latest git revision on the main branch?  Please double check that the
libraries shown in /usr/local/lib64 look up to date (ls -l
/usr/local/lib64).

It seems from that backtrace that the crash occurred in relation to a zone
being removed (can't tell if it is a preset or instrument zone).  It seems
it got removed and then the crash occurs in the GtkTree related code, which
is probably still trying to access a deleted item or something.

I just opened up that SoundFont and went on a deleting spree without ill
effect.  If you could get a general idea of what kinds of operations you
are performing during a session, that might help me to reproduce it.

It could be there is something happening with library versions or other
weirdness on your system though.  If the backtraces seem fairly
inconsistent this could point more to this possibility.  For example if
libInstPatch and Swami are out of sync, because of duplicate libraries
somewhere or something like that.  If in doubt delete libInstPatch and
Swami from /usr/local and make clean/rebuild libInstPatch and Swami.

When things get really random with memory corruption issues, I will
sometimes use valgrind (like so: valgrind --tool=memcheck
--trace-children=yes swami).  This has the side effect of slowing the
application quite a bit, but it will often catch the first sign of memory
corruption occurring which is extremely helpful.  I just did this and
didn't find anything real noteworthy until exiting the application, where
some invalid memory reads were occurring.  Probably not related to what you
are experiencing though.

Best regards,

Element


On Tue, Jul 5, 2016 at 1:46 PM, Aaron Laws <dar...@gm...> wrote:

>
> Here's a backtrace:
>
> #0  0x00007ffff64a6295 in raise () from /usr/lib/libc.so.6
> #1  0x00007ffff64a76da in abort () from /usr/lib/libc.so.6
> #2  0x00007ffff6b5f485 in g_assertion_message () from
> /usr/lib/libglib-2.0.so.0
> #3  0x00007ffff6b5f51a in g_assertion_message_expr () from
> /usr/lib/libglib-2.0.so.0
> #4  0x00007ffff7520c10 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #5  0x00007ffff7522f98 in gtk_tree_store_set_valist () from
> /usr/lib/libgtk-x11-2.0.so.0
> #6  0x00007ffff7523054 in gtk_tree_store_set () from
> /usr/lib/libgtk-x11-2.0.so.0
> #7  0x00007ffff7bb6f6f in swamigui_tree_store_change () from
> /usr/local/lib64/libswamigui.so.0
> #8  0x00007ffff7ba3695 in swamigui_root_update_solo_item () from
> /usr/local/lib64/libswamigui.so.0
> #9  0x00007ffff7ba381a in swamigui_root_cb_solo_item () from
> /usr/local/lib64/libswamigui.so.0
> #10 0x00007ffff6e0efa5 in g_closure_invoke () from
> /usr/lib/libgobject-2.0.so.0
> #11 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
> #12 0x00007ffff6e29c1c in g_signal_emit_valist () from
> /usr/lib/libgobject-2.0.so.0
> #13 0x00007ffff6e29fff in g_signal_emit () from
> /usr/lib/libgobject-2.0.so.0
> #14 0x00007ffff6e133d4 in ?? () from /usr/lib/libgobject-2.0.so.0
> #15 0x00007ffff6e12c76 in ?? () from /usr/lib/libgobject-2.0.so.0
> #16 0x00007ffff6e17160 in g_object_set_property () from
> /usr/lib/libgobject-2.0.so.0
> #17 0x00007ffff7957d21 in control_prop_set_value_method () from
> /usr/local/lib64/libswami.so.0
> #18 0x00007ffff7954e88 in swami_control_set_event () from
> /usr/local/lib64/libswami.so.0
> #19 0x00007ffff7956b7e in swami_control_transmit_value () from
> /usr/local/lib64/libswami.so.0
> #20 0x00007ffff7957960 in swami_control_prop_cb_notify () from
> /usr/local/lib64/libswami.so.0
> #21 0x00007ffff6e0efa5 in g_closure_invoke () from
> /usr/lib/libgobject-2.0.so.0
> #22 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
> #23 0x00007ffff6e29c1c in g_signal_emit_valist () from
> /usr/lib/libgobject-2.0.so.0
> #24 0x00007ffff6e29fff in g_signal_emit () from
> /usr/lib/libgobject-2.0.so.0
> #25 0x00007ffff6e133d4 in ?? () from /usr/lib/libgobject-2.0.so.0
> #26 0x00007ffff6e15891 in g_object_notify () from
> /usr/lib/libgobject-2.0.so.0
> #27 0x00007ffff7bb30cf in swamigui_tree_update_selection () from
> /usr/local/lib64/libswamigui.so.0
> #28 0x00007ffff6e0f1d4 in ?? () from /usr/lib/libgobject-2.0.so.0
> #29 0x00007ffff6e2990d in g_signal_emit_valist () from
> /usr/lib/libgobject-2.0.so.0
> #30 0x00007ffff6e2a4ab in g_signal_emit_by_name () from
> /usr/lib/libgobject-2.0.so.0
> #31 0x00007ffff752bfd7 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #32 0x00007ffff6e0efa5 in g_closure_invoke () from
> /usr/lib/libgobject-2.0.so.0
> #33 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
> #34 0x00007ffff6e29c1c in g_signal_emit_valist () from
> /usr/lib/libgobject-2.0.so.0
> #35 0x00007ffff6e29fff in g_signal_emit () from
> /usr/lib/libgobject-2.0.so.0
> #36 0x00007ffff75231c0 in gtk_tree_store_remove () from
> /usr/lib/libgtk-x11-2.0.so.0
> #37 0x00007ffff7bb7403 in swamigui_tree_store_remove () from
> /usr/local/lib64/libswamigui.so.0
> #38 0x00007ffff7ba3c00 in ctrl_remove_set_func () from
> /usr/local/lib64/libswamigui.so.0
> #39 0x00007ffff7954e88 in swami_control_set_event () from
> /usr/local/lib64/libswami.so.0
> #40 0x00007ffff79557ee in swami_control_transmit_event () from
> /usr/local/lib64/libswami.so.0
> #41 0x00007ffff79639db in container_remove_notify () from
> /usr/local/lib64/libswami.so.0
> #42 0x00007ffff68407f5 in ipatch_container_remove_notify () from
> /usr/local/lib64/libinstpatch-1.0.so.0
> #43 0x00007ffff683f2ab in ipatch_container_remove () from
> /usr/local/lib64/libinstpatch-1.0.so.0
> #44 0x00007ffff6864a30 in ipatch_item_item_remove_full () from
> /usr/local/lib64/libinstpatch-1.0.so.0
> #45 0x00007ffff689cc12 in ipatch_sf2_zone_item_remove_full () from
> /usr/local/lib64/libinstpatch-1.0.so.0
> #46 0x00007ffff6865aba in ipatch_item_real_remove_full () from
> /usr/local/lib64/libinstpatch-1.0.so.0
> #47 0x00007ffff68659d6 in ipatch_item_remove () from
> /usr/local/lib64/libinstpatch-1.0.so.0
> #48 0x00007ffff7bba3a2 in swamigui_delete_items () from
> /usr/local/lib64/libswamigui.so.0
> #49 0x00007ffff7b93d28 in swamigui_item_menu_callback_activate () from
> /usr/local/lib64/libswamigui.so.0
> #50 0x00007ffff6e0efa5 in g_closure_invoke () from
> /usr/lib/libgobject-2.0.so.0
> #51 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
> #52 0x00007ffff6e29c1c in g_signal_emit_valist () from
> /usr/lib/libgobject-2.0.so.0
> #53 0x00007ffff6e29fff in g_signal_emit () from
> /usr/lib/libgobject-2.0.so.0
> #54 0x00007ffff754f06e in gtk_widget_activate () from
> /usr/lib/libgtk-x11-2.0.so.0
> #55 0x00007ffff744a6dd in gtk_menu_shell_activate_item () from
> /usr/lib/libgtk-x11-2.0.so.0
> #56 0x00007ffff744aa46 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #57 0x00007ffff743891c in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #58 0x00007ffff6e0efa5 in g_closure_invoke () from
> /usr/lib/libgobject-2.0.so.0
> #59 0x00007ffff6e213ad in ?? () from /usr/lib/libgobject-2.0.so.0
> #60 0x00007ffff6e296bf in g_signal_emit_valist () from
> /usr/lib/libgobject-2.0.so.0
> #61 0x00007ffff6e29fff in g_signal_emit () from
> /usr/lib/libgobject-2.0.so.0
> #62 0x00007ffff75502dc in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #63 0x00007ffff74370b4 in gtk_propagate_event () from
> /usr/lib/libgtk-x11-2.0.so.0
> #64 0x00007ffff743746b in gtk_main_do_event () from
> /usr/lib/libgtk-x11-2.0.so.0
> #65 0x00007ffff70ac3ac in ?? () from /usr/lib/libgdk-x11-2.0.so.0
> #66 0x00007ffff6b39dd7 in g_main_context_dispatch () from
> /usr/lib/libglib-2.0.so.0
> #67 0x00007ffff6b3a040 in ?? () from /usr/lib/libglib-2.0.so.0
> #68 0x00007ffff6b3a362 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
> #69 0x00007ffff74364e7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
> #70 0x0000000000401409 in main ()
>
> I'm not sure how to reproduce this error. Like I said, I can do the thing
> I want to do after a restart, so I guess there's some longer-term
> corruption taking place.
>
> In Christ,
> Aaron Laws
>

Re: [Swami-devel] Segmentation Fault

[Element G. <el...@el...>]

On Tue, Jul 5, 2016 at 1:20 PM, Aaron Laws <dar...@gm...> wrote:
>
>
> Just now, again, when trying to remove 4 or so non-contiguous instruments
> from a melodic preset, I got:
>
>  ** (swami:31545): CRITICAL **: ipatch_unit_convert: assertion 'src_info
> != NULL' failed
> Segmentation fault (core dumped)
>
> the swami:31545 message was posted several times, and not just when the
> failure happened, but over the course of my work.
>
> It's worth mentioning that I restarted swami, and did the exact same
> thing, but it worked this time.
>
>
> A little later, I get:
> (swami:32394): GnomeCanvas-CRITICAL **: gnome_canvas_item_lower_to_bottom:
> assertion 'GNOME_IS_CANVAS_ITEM (item)' failed
> (swami:32394): GLib-GObject-CRITICAL **: g_object_set: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:32394): GLib-GObject-WARNING **: invalid unclassed pointer in cast
> to 'GtkObject'
> (swami:32394): Gtk-CRITICAL **: IA__gtk_object_destroy: assertion
> 'GTK_IS_OBJECT (object)' failed
> (swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> Segmentation fault (core dumped)
>
> A couple minutes later:
>
> (swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:1432): GLib-GObject-WARNING **: instance of invalid
> non-instantiatable type '<invalid>'
> (swami:1432): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion
> 'G_TYPE_CHECK_INSTANCE (instance)' failed
> (swami:1432): GLib-GObject-WARNING **: instance of invalid
> non-instantiatable type '<invalid>'
> (swami:1432): GLib-GObject-CRITICAL **: g_signal_handlers_destroy:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> (swami:1432): GLib-GObject-WARNING **: instance of invalid
> non-instantiatable type '<invalid>'
> (swami:1432): GLib-GObject-CRITICAL **: g_signal_handlers_destroy:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> (swami:1432): GnomeCanvas-CRITICAL **: gnome_canvas_item_raise_to_top:
> assertion 'GNOME_IS_CANVAS_ITEM (item)' failed
> (swami:1432): GLib-GObject-CRITICAL **: g_object_set: assertion
> 'G_IS_OBJECT (object)' failed
> (swami:1432): GnomeCanvas-CRITICAL **: gnome_canvas_item_lower_to_bottom:
> assertion 'GNOME_IS_CANVAS_ITEM (item)' failed
> (swami:1432): GLib-GObject-CRITICAL **: g_object_set: assertion
> 'G_IS_OBJECT (object)' failed
> **
> Gtk:ERROR:gtktreestore.c:522:gtk_tree_store_get_path: assertion failed:
> (G_NODE (iter->user_data)->parent != NULL)
> Aborted (core dumped)
>
>

It's hard to tell what is going on from those messages.  Backtraces would
really help, which it looks like you have one in the next email, which I'll
respond to.



>
> I see your response already. I just checked, and I made from cmake. I'll
> run from gdb and see what I can see. I'm on commit d27e8ed. I just ran git
> fetch, and I see that you've been committing a lot lately!
>
> Should I try the stable branch?
>
>

Yes, lots of work lately.  It feels nice getting back in to developing
Swami.  Development has been very stagnant for several years.  I had
originally created the "stable" branch in the interest of making a long
overdue release (Swami 2.1 and libInstPatch 1.1.0).  After jumping back in
the saddle I decided not to do this, but to work on "doing things the right
way".  I've been overly careful about breaking the API with libInstPatch in
particular.  I've decided not to worry about it anymore, since there aren't
that many programs using it currently and they can just deal ;-)

After making some very significant changes to fix some bugs related to
sample data migration when saving SoundFont files (which can lead to sample
data corruption), I started to realize the importance of a test suite.
After playing more with the GObject Introspection binding, I thought how
cool it would be to use Python as a test platform, since it is really easy
to use an interactive Python shell, etc.  So I'm improving the GObject
Introspection binding and creating a Python based test suite.  This will
ultimately lead to a more stable, well written, and tested API.

So, I would not recommend the "stable" branch and I may just delete it at
this point, since it is quickly diverging from the main development
branch.  The revision you had is pretty old, back when I forked the stable
branch.  If you are willing to test the latest and greatest, that would be
totally awesome and would provide some very valuable beta testing.  Though
I would suggest keeping many backups of your valuable editing work, just in
case it does something bad.

Cheers!

Element

Re: [Swami-devel] Segmentation Fault

[Aaron L. <dar...@gm...>]

On Tue, Jul 5, 2016 at 3:11 PM, Element Green <el...@el...>
wrote:

> Hello Aaron,
>
> I also have the SoundFont you mentioned, but I don't believe I have
> experienced a crash with it particularly.
>
> What version of Swami are you using?  Is it from a binary package in your
> distribution or from source code?  I have recently been doing a lot of
> development (the past week), after many years of inactivity.  Perhaps you
> are using the bleeding edge git master branch which is currently in heavy
> development?  If you aren't, then it would be nice to see if you experience
> crashes with it as well, since it may actually be in better shape that what
> you are currently using.
>
> I just loaded up that SoundFont and also see that it complains about
> invalid UTF-8 strings.  It would be nice to handle this properly.  I don't
> seem to remember anything in the SoundFont spec about character encodings,
> so that may mean there are a lot of variations in the wild.  Could be a
> mess.  But at least allowing some way to select the character encoding or
> try and detect it might be nice.
>
> As far as debugging things..  You'll probably want to build Swami from
> source with debugging enabled.  Otherwise backtraces will be less than
> useful.  This isn't enabled by default.  Let me know if you want to try
> this and need any assistance.  I suggest using cmake to build it rather
> than autoconf (I'm considering dropping autoconf build support).  You would
> then start up swami in a terminal like:
> gdb swami [ENTER]
>
> Then type 'r' and ENTER to run the program.  Do stuff, wait for it to
> crash which will show the GDB prompt again and then do:
> bt [ENTER]
>
> That should give you a backtrace, that you can copy/paste.
>
> Best regards,
>
> Element
>

Here's a backtrace:

#0  0x00007ffff64a6295 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff64a76da in abort () from /usr/lib/libc.so.6
#2  0x00007ffff6b5f485 in g_assertion_message () from
/usr/lib/libglib-2.0.so.0
#3  0x00007ffff6b5f51a in g_assertion_message_expr () from
/usr/lib/libglib-2.0.so.0
#4  0x00007ffff7520c10 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#5  0x00007ffff7522f98 in gtk_tree_store_set_valist () from
/usr/lib/libgtk-x11-2.0.so.0
#6  0x00007ffff7523054 in gtk_tree_store_set () from
/usr/lib/libgtk-x11-2.0.so.0
#7  0x00007ffff7bb6f6f in swamigui_tree_store_change () from
/usr/local/lib64/libswamigui.so.0
#8  0x00007ffff7ba3695 in swamigui_root_update_solo_item () from
/usr/local/lib64/libswamigui.so.0
#9  0x00007ffff7ba381a in swamigui_root_cb_solo_item () from
/usr/local/lib64/libswamigui.so.0
#10 0x00007ffff6e0efa5 in g_closure_invoke () from
/usr/lib/libgobject-2.0.so.0
#11 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
#12 0x00007ffff6e29c1c in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#13 0x00007ffff6e29fff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#14 0x00007ffff6e133d4 in ?? () from /usr/lib/libgobject-2.0.so.0
#15 0x00007ffff6e12c76 in ?? () from /usr/lib/libgobject-2.0.so.0
#16 0x00007ffff6e17160 in g_object_set_property () from
/usr/lib/libgobject-2.0.so.0
#17 0x00007ffff7957d21 in control_prop_set_value_method () from
/usr/local/lib64/libswami.so.0
#18 0x00007ffff7954e88 in swami_control_set_event () from
/usr/local/lib64/libswami.so.0
#19 0x00007ffff7956b7e in swami_control_transmit_value () from
/usr/local/lib64/libswami.so.0
#20 0x00007ffff7957960 in swami_control_prop_cb_notify () from
/usr/local/lib64/libswami.so.0
#21 0x00007ffff6e0efa5 in g_closure_invoke () from
/usr/lib/libgobject-2.0.so.0
#22 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
#23 0x00007ffff6e29c1c in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#24 0x00007ffff6e29fff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#25 0x00007ffff6e133d4 in ?? () from /usr/lib/libgobject-2.0.so.0
#26 0x00007ffff6e15891 in g_object_notify () from
/usr/lib/libgobject-2.0.so.0
#27 0x00007ffff7bb30cf in swamigui_tree_update_selection () from
/usr/local/lib64/libswamigui.so.0
#28 0x00007ffff6e0f1d4 in ?? () from /usr/lib/libgobject-2.0.so.0
#29 0x00007ffff6e2990d in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#30 0x00007ffff6e2a4ab in g_signal_emit_by_name () from
/usr/lib/libgobject-2.0.so.0
#31 0x00007ffff752bfd7 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#32 0x00007ffff6e0efa5 in g_closure_invoke () from
/usr/lib/libgobject-2.0.so.0
#33 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
#34 0x00007ffff6e29c1c in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#35 0x00007ffff6e29fff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#36 0x00007ffff75231c0 in gtk_tree_store_remove () from
/usr/lib/libgtk-x11-2.0.so.0
#37 0x00007ffff7bb7403 in swamigui_tree_store_remove () from
/usr/local/lib64/libswamigui.so.0
#38 0x00007ffff7ba3c00 in ctrl_remove_set_func () from
/usr/local/lib64/libswamigui.so.0
#39 0x00007ffff7954e88 in swami_control_set_event () from
/usr/local/lib64/libswami.so.0
#40 0x00007ffff79557ee in swami_control_transmit_event () from
/usr/local/lib64/libswami.so.0
#41 0x00007ffff79639db in container_remove_notify () from
/usr/local/lib64/libswami.so.0
#42 0x00007ffff68407f5 in ipatch_container_remove_notify () from
/usr/local/lib64/libinstpatch-1.0.so.0
#43 0x00007ffff683f2ab in ipatch_container_remove () from
/usr/local/lib64/libinstpatch-1.0.so.0
#44 0x00007ffff6864a30 in ipatch_item_item_remove_full () from
/usr/local/lib64/libinstpatch-1.0.so.0
#45 0x00007ffff689cc12 in ipatch_sf2_zone_item_remove_full () from
/usr/local/lib64/libinstpatch-1.0.so.0
#46 0x00007ffff6865aba in ipatch_item_real_remove_full () from
/usr/local/lib64/libinstpatch-1.0.so.0
#47 0x00007ffff68659d6 in ipatch_item_remove () from
/usr/local/lib64/libinstpatch-1.0.so.0
#48 0x00007ffff7bba3a2 in swamigui_delete_items () from
/usr/local/lib64/libswamigui.so.0
#49 0x00007ffff7b93d28 in swamigui_item_menu_callback_activate () from
/usr/local/lib64/libswamigui.so.0
#50 0x00007ffff6e0efa5 in g_closure_invoke () from
/usr/lib/libgobject-2.0.so.0
#51 0x00007ffff6e20fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
#52 0x00007ffff6e29c1c in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#53 0x00007ffff6e29fff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#54 0x00007ffff754f06e in gtk_widget_activate () from
/usr/lib/libgtk-x11-2.0.so.0
#55 0x00007ffff744a6dd in gtk_menu_shell_activate_item () from
/usr/lib/libgtk-x11-2.0.so.0
#56 0x00007ffff744aa46 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#57 0x00007ffff743891c in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#58 0x00007ffff6e0efa5 in g_closure_invoke () from
/usr/lib/libgobject-2.0.so.0
#59 0x00007ffff6e213ad in ?? () from /usr/lib/libgobject-2.0.so.0
#60 0x00007ffff6e296bf in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#61 0x00007ffff6e29fff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#62 0x00007ffff75502dc in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#63 0x00007ffff74370b4 in gtk_propagate_event () from
/usr/lib/libgtk-x11-2.0.so.0
#64 0x00007ffff743746b in gtk_main_do_event () from
/usr/lib/libgtk-x11-2.0.so.0
#65 0x00007ffff70ac3ac in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#66 0x00007ffff6b39dd7 in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#67 0x00007ffff6b3a040 in ?? () from /usr/lib/libglib-2.0.so.0
#68 0x00007ffff6b3a362 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#69 0x00007ffff74364e7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#70 0x0000000000401409 in main ()

I'm not sure how to reproduce this error. Like I said, I can do the thing I
want to do after a restart, so I guess there's some longer-term corruption
taking place.

In Christ,
Aaron Laws

Re: [Swami-devel] Segmentation Fault

[Aaron L. <dar...@gm...>]

On Tue, Jul 5, 2016 at 2:52 PM, Aaron Laws <dar...@gm...> wrote:

> I just started using swami to create a new sound font based on an existing
> one. I experience segmentation faults quite often. The font that I'm
> editing is Jeux 1.4 (http://www.realmac.info/download.htm) which seems to
> have some bogus characters. O-umlaut and other characters with accents
> don't show up properly. I haven't investigated closely, but it seems like
> they might be encoded as UTF-16? Anyway, swami complained quite a bit about
> "invalid UTF-8 strings", and I removed all the bogus characters I can see.
>
> That didn't stop the crashing, however. It usually happens when I delete
> (e.g.) an instrument from a melodic preset. The error is:
>
> Gtk:ERROR:gtktreestore.c:522:gtk_tree_store_get_path: assertion failed:
> (G_NODE (iter->user_data)->parent != NULL)
> Aborted (core dumped)
>
> The crashes are frequent enough that I'm saving very often now (so,
> perhaps a good thing after all). Happily, swami starts back up pretty
> quickly. I'll keep an eye on it and see if I ever get a different message.
>
> Also, please let me know if there's a startup parameter or something else
> I can do to get more output (stack track?), etc.
>
> In Christ,
> Aaron Laws
>
>

Just now, again, when trying to remove 4 or so non-contiguous instruments
from a melodic preset, I got:

 ** (swami:31545): CRITICAL **: ipatch_unit_convert: assertion 'src_info !=
NULL' failed
Segmentation fault (core dumped)

the swami:31545 message was posted several times, and not just when the
failure happened, but over the course of my work.

It's worth mentioning that I restarted swami, and did the exact same thing,
but it worked this time.


A little later, I get:
(swami:32394): GnomeCanvas-CRITICAL **: gnome_canvas_item_lower_to_bottom:
assertion 'GNOME_IS_CANVAS_ITEM (item)' failed
(swami:32394): GLib-GObject-CRITICAL **: g_object_set: assertion
'G_IS_OBJECT (object)' failed
(swami:32394): GLib-GObject-WARNING **: invalid unclassed pointer in cast
to 'GtkObject'
(swami:32394): Gtk-CRITICAL **: IA__gtk_object_destroy: assertion
'GTK_IS_OBJECT (object)' failed
(swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
'G_IS_OBJECT (object)' failed
(swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
'G_IS_OBJECT (object)' failed
(swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
'G_IS_OBJECT (object)' failed
(swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
'G_IS_OBJECT (object)' failed
(swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
'G_IS_OBJECT (object)' failed
(swami:32394): GLib-GObject-CRITICAL **: g_object_unref: assertion
'G_IS_OBJECT (object)' failed
Segmentation fault (core dumped)

A couple minutes later:

(swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
'G_IS_OBJECT (object)' failed
(swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
'G_IS_OBJECT (object)' failed
(swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
'G_IS_OBJECT (object)' failed
(swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
'G_IS_OBJECT (object)' failed
(swami:1432): GLib-GObject-CRITICAL **: g_object_unref: assertion
'G_IS_OBJECT (object)' failed
(swami:1432): GLib-GObject-WARNING **: instance of invalid
non-instantiatable type '<invalid>'
(swami:1432): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion
'G_TYPE_CHECK_INSTANCE (instance)' failed
(swami:1432): GLib-GObject-WARNING **: instance of invalid
non-instantiatable type '<invalid>'
(swami:1432): GLib-GObject-CRITICAL **: g_signal_handlers_destroy:
assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
(swami:1432): GLib-GObject-WARNING **: instance of invalid
non-instantiatable type '<invalid>'
(swami:1432): GLib-GObject-CRITICAL **: g_signal_handlers_destroy:
assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
(swami:1432): GnomeCanvas-CRITICAL **: gnome_canvas_item_raise_to_top:
assertion 'GNOME_IS_CANVAS_ITEM (item)' failed
(swami:1432): GLib-GObject-CRITICAL **: g_object_set: assertion
'G_IS_OBJECT (object)' failed
(swami:1432): GnomeCanvas-CRITICAL **: gnome_canvas_item_lower_to_bottom:
assertion 'GNOME_IS_CANVAS_ITEM (item)' failed
(swami:1432): GLib-GObject-CRITICAL **: g_object_set: assertion
'G_IS_OBJECT (object)' failed
**
Gtk:ERROR:gtktreestore.c:522:gtk_tree_store_get_path: assertion failed:
(G_NODE (iter->user_data)->parent != NULL)
Aborted (core dumped)


I see your response already. I just checked, and I made from cmake. I'll
run from gdb and see what I can see. I'm on commit d27e8ed. I just ran git
fetch, and I see that you've been committing a lot lately!

Should I try the stable branch?