You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
(16) |
Apr
(20) |
May
(30) |
Jun
(34) |
Jul
(5) |
Aug
(5) |
Sep
(7) |
Oct
(1) |
Nov
(3) |
Dec
(16) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(80) |
Feb
(2) |
Mar
(18) |
Apr
(7) |
May
(1) |
Jun
(10) |
Jul
(5) |
Aug
(7) |
Sep
(5) |
Oct
|
Nov
(2) |
Dec
(19) |
2004 |
Jan
(20) |
Feb
(18) |
Mar
(3) |
Apr
(6) |
May
(11) |
Jun
(7) |
Jul
(16) |
Aug
|
Sep
(10) |
Oct
(4) |
Nov
(13) |
Dec
|
2005 |
Jan
(6) |
Feb
|
Mar
(29) |
Apr
(7) |
May
(8) |
Jun
(17) |
Jul
|
Aug
(46) |
Sep
(17) |
Oct
(18) |
Nov
(20) |
Dec
|
2006 |
Jan
(1) |
Feb
(14) |
Mar
(32) |
Apr
(14) |
May
(5) |
Jun
(3) |
Jul
(10) |
Aug
(19) |
Sep
|
Oct
|
Nov
(4) |
Dec
(17) |
2007 |
Jan
(13) |
Feb
|
Mar
|
Apr
(15) |
May
(20) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(10) |
Dec
(1) |
2008 |
Jan
(6) |
Feb
(1) |
Mar
(4) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(15) |
Sep
|
Oct
(4) |
Nov
|
Dec
(5) |
2009 |
Jan
(12) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(2) |
2010 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(23) |
Nov
(32) |
Dec
|
2011 |
Jan
(20) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
2012 |
Jan
|
Feb
(4) |
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(16) |
Dec
(35) |
2013 |
Jan
(7) |
Feb
(18) |
Mar
(8) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(23) |
Nov
(23) |
Dec
|
2014 |
Jan
|
Feb
|
Mar
(42) |
Apr
(61) |
May
(13) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(12) |
2016 |
Jan
|
Feb
(1) |
Mar
(5) |
Apr
|
May
|
Jun
(9) |
Jul
(15) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2018 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Element G. <el...@ky...> - 2020-12-28 22:09:24
|
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 |
From: S. C. C. <s.c...@gm...> - 2018-09-11 23:42:12
|
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 |
From: Element G. <el...@el...> - 2018-01-02 02:37:58
|
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 > > |
From: Jaromír M. <mir...@gm...> - 2018-01-01 18:47:22
|
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 |
From: Element G. <jg...@us...> - 2018-01-01 17:34:44
|
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 > |
From: Jaromír M. <mir...@gm...> - 2017-12-29 22:29:48
|
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 |
From: Jonathan H. <jh...@ho...> - 2017-01-30 09:32:19
|
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 |
From: Element G. <el...@el...> - 2016-08-20 15:50:46
|
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 |
From: S. C. C. <s.c...@gm...> - 2016-08-19 15:53:30
|
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 |
From: Element G. <el...@el...> - 2016-08-19 05:29:21
|
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 |
From: S. C. C. <s.c...@gm...> - 2016-08-10 05:03:47
|
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 |
From: Element G. <el...@el...> - 2016-08-01 05:26:55
|
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> |
From: Element G. <el...@el...> - 2016-07-06 16:35:55
|
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 > |
From: Aaron L. <dar...@gm...> - 2016-07-06 13:01:10
|
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 |
From: Aaron L. <dar...@gm...> - 2016-07-06 12:42:14
|
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! |
From: Aaron L. <dar...@gm...> - 2016-07-06 12:40:49
|
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 |
From: Element G. <el...@el...> - 2016-07-06 08:37:56
|
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 |
From: Element G. <el...@el...> - 2016-07-06 07:13:18
|
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 >> > > |
From: <ra...@hy...> - 2016-07-06 03:17:30
|
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 > ****************************************** > |
From: Element G. <el...@el...> - 2016-07-05 20:58:37
|
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 > |
From: Aaron L. <dar...@gm...> - 2016-07-05 20:49:40
|
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 |
From: Element G. <el...@el...> - 2016-07-05 20:16:10
|
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 > |
From: Element G. <el...@el...> - 2016-07-05 19:48:32
|
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 |
From: Aaron L. <dar...@gm...> - 2016-07-05 19:47:16
|
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 |
From: Aaron L. <dar...@gm...> - 2016-07-05 19:21:22
|
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? |