linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

Re: [Linuxsampler-devel] [linuxsampler-devel] "Cannot load file: Unknown leverage controller type"

[Andrew C <cou...@gm...>]

I also tried opening the offending file in Translator 6 Free. It opened
fine and I could see all the programs and preview all the wav samples
inside, so I'm certain the file is not corrupted at least.

I also came across this thread and I see that leverage controller 0x2 isn't
listed there. Seems like it's a bug/glitch that LS is having... :S

https://bb.linuxsampler.org/viewtopic.php?f=6&t=376

Andrew.

On Sun, May 21, 2017 at 2:40 PM, Andrew C <cou...@gm...> wrote:

> Loading gig instrument ('/media/andrew/Seagate Expansion
> Drive/WS_MS_BbClarinet_GS3/Clarinet (Bb)_Long
> Notes_Legato_Glissando.gig',1)...gig::Engine error: Failed to load
> instrument, cause: Unknown leverage controller type (0x2).
>
> Is what I get back. :\
>
> This was actually a fresh download from Big Fish Audio, the site I bought
> it from, and all the other included gig files load and work fine except for
> this file.
>
> On Sun, May 21, 2017 at 2:16 PM, Christian Schoenebeck <
> sch...@li...> wrote:
>
>> On Sunday, May 21, 2017 12:22:50 Andrew C wrote:
>> > I cannot load the Eb Clarinet long notes giga file from Westgate Studios
>> > into Linuxsampler.
>> >
>> > I get the error "Cannot load file: Unknown leverage controller type".
>>
>> Chances that the file might be corrupt? I.e. was it on a unreliable media
>> for
>> a long time or something? Because libgig should support all known leverage
>> controllers of up to the latest version of GigaStudio, and you know there
>> was
>> no new GigaStudio version for many years now.
>>
>> I just committed a change to libgig which will show the precise leverage
>> controller number when this exception is thrown. So please update libgig
>> to
>> latest SVN and recompile, then the exception should look something like
>> this:
>>
>>         RIFF::Exception: Unknown leverage controller type (0xfc).
>>
>> > Now the gig file, according to its manual, has some fancy
>> imidi/GigaStudio
>> > specific scripting for Legato which I thought I could see if I could get
>> > working with gigedit... But this error appeared.
>>
>> These are Tascam's so called "Legato Rules", which are supported by
>> libgig and
>> gigedit, but ATM they are not supported by LinuxSampler. So you can load
>> those
>> sounds with the sampler, but the legato rules will be ignored by the
>> sampler
>> engine ATM. The MIDI control trigger rules are supported by the sampler
>> though
>> BTW.
>>
>> Actually I wanted to implement the legato rules for the sampler, but when
>> I
>> looked at it I thought this is far too limited. Just open such a gig file
>> with
>> gigedit and open the "MIDI Rules" editor for that and you might get an
>> idea
>> about it. Basically what it does is defining a small set of samples which
>> shall be played for resembling legato behavior from one certain key to
>> another. So the sound designer had to bundle a separate audio sample for
>> the
>> individual possibilities of tone transitions. And there two problems: the
>> total amount of samples was very limited (I can't remember how many, about
>> 24?, Andreas might tell you though) and you could not customize anything
>> on
>> that legato behavior for your sounds.
>>
>> So the legato rules are *not* scripting. Due to all those limitations
>> found, I
>> rather decided starting to implement the real-time instrument script
>> feature
>> instead. With that new scripting feature you can do everything those iMIDI
>> rules could do, but also much more than that.
>>
>> > There are also .gsi files inside the directory relating to Legato, but I
>> > don't think they're supported by linuxsampler at this time?
>>
>> They are not supported, and right now I can't even remember which
>> extension
>> was for what. I think this one was for defining a stack of instrument
>> combinations. There was also a file for saving impulse response samples
>> for
>> GigaPulse, I think those were .gsp files, but we are not supporting them
>> either.
>>
>> Andreas might tell you more about the unsupported GSt file types.
>>
>> CU
>> Christian
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Linuxsampler-devel mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>>
>
>

Re: [Linuxsampler-devel] [linuxsampler-devel] "Cannot load file: Unknown leverage controller type"

[Andrew C <cou...@gm...>]

Loading gig instrument ('/media/andrew/Seagate Expansion
Drive/WS_MS_BbClarinet_GS3/Clarinet (Bb)_Long
Notes_Legato_Glissando.gig',1)...gig::Engine error: Failed to load
instrument, cause: Unknown leverage controller type (0x2).

Is what I get back. :\

This was actually a fresh download from Big Fish Audio, the site I bought
it from, and all the other included gig files load and work fine except for
this file.

On Sun, May 21, 2017 at 2:16 PM, Christian Schoenebeck <
sch...@li...> wrote:

> On Sunday, May 21, 2017 12:22:50 Andrew C wrote:
> > I cannot load the Eb Clarinet long notes giga file from Westgate Studios
> > into Linuxsampler.
> >
> > I get the error "Cannot load file: Unknown leverage controller type".
>
> Chances that the file might be corrupt? I.e. was it on a unreliable media
> for
> a long time or something? Because libgig should support all known leverage
> controllers of up to the latest version of GigaStudio, and you know there
> was
> no new GigaStudio version for many years now.
>
> I just committed a change to libgig which will show the precise leverage
> controller number when this exception is thrown. So please update libgig to
> latest SVN and recompile, then the exception should look something like
> this:
>
>         RIFF::Exception: Unknown leverage controller type (0xfc).
>
> > Now the gig file, according to its manual, has some fancy
> imidi/GigaStudio
> > specific scripting for Legato which I thought I could see if I could get
> > working with gigedit... But this error appeared.
>
> These are Tascam's so called "Legato Rules", which are supported by libgig
> and
> gigedit, but ATM they are not supported by LinuxSampler. So you can load
> those
> sounds with the sampler, but the legato rules will be ignored by the
> sampler
> engine ATM. The MIDI control trigger rules are supported by the sampler
> though
> BTW.
>
> Actually I wanted to implement the legato rules for the sampler, but when I
> looked at it I thought this is far too limited. Just open such a gig file
> with
> gigedit and open the "MIDI Rules" editor for that and you might get an idea
> about it. Basically what it does is defining a small set of samples which
> shall be played for resembling legato behavior from one certain key to
> another. So the sound designer had to bundle a separate audio sample for
> the
> individual possibilities of tone transitions. And there two problems: the
> total amount of samples was very limited (I can't remember how many, about
> 24?, Andreas might tell you though) and you could not customize anything on
> that legato behavior for your sounds.
>
> So the legato rules are *not* scripting. Due to all those limitations
> found, I
> rather decided starting to implement the real-time instrument script
> feature
> instead. With that new scripting feature you can do everything those iMIDI
> rules could do, but also much more than that.
>
> > There are also .gsi files inside the directory relating to Legato, but I
> > don't think they're supported by linuxsampler at this time?
>
> They are not supported, and right now I can't even remember which extension
> was for what. I think this one was for defining a stack of instrument
> combinations. There was also a file for saving impulse response samples for
> GigaPulse, I think those were .gsp files, but we are not supporting them
> either.
>
> Andreas might tell you more about the unsupported GSt file types.
>
> CU
> Christian
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] [linuxsampler-devel] "Cannot load file: Unknown leverage controller type"

[Christian S. <sch...@li...>]

On Sunday, May 21, 2017 12:22:50 Andrew C wrote:
> I cannot load the Eb Clarinet long notes giga file from Westgate Studios
> into Linuxsampler.
> 
> I get the error "Cannot load file: Unknown leverage controller type".

Chances that the file might be corrupt? I.e. was it on a unreliable media for 
a long time or something? Because libgig should support all known leverage 
controllers of up to the latest version of GigaStudio, and you know there was 
no new GigaStudio version for many years now.

I just committed a change to libgig which will show the precise leverage 
controller number when this exception is thrown. So please update libgig to 
latest SVN and recompile, then the exception should look something like this:

	RIFF::Exception: Unknown leverage controller type (0xfc).

> Now the gig file, according to its manual, has some fancy imidi/GigaStudio
> specific scripting for Legato which I thought I could see if I could get
> working with gigedit... But this error appeared.

These are Tascam's so called "Legato Rules", which are supported by libgig and 
gigedit, but ATM they are not supported by LinuxSampler. So you can load those 
sounds with the sampler, but the legato rules will be ignored by the sampler 
engine ATM. The MIDI control trigger rules are supported by the sampler though 
BTW.

Actually I wanted to implement the legato rules for the sampler, but when I 
looked at it I thought this is far too limited. Just open such a gig file with 
gigedit and open the "MIDI Rules" editor for that and you might get an idea 
about it. Basically what it does is defining a small set of samples which 
shall be played for resembling legato behavior from one certain key to 
another. So the sound designer had to bundle a separate audio sample for the 
individual possibilities of tone transitions. And there two problems: the 
total amount of samples was very limited (I can't remember how many, about 
24?, Andreas might tell you though) and you could not customize anything on 
that legato behavior for your sounds.

So the legato rules are *not* scripting. Due to all those limitations found, I 
rather decided starting to implement the real-time instrument script feature 
instead. With that new scripting feature you can do everything those iMIDI 
rules could do, but also much more than that.

> There are also .gsi files inside the directory relating to Legato, but I
> don't think they're supported by linuxsampler at this time?

They are not supported, and right now I can't even remember which extension 
was for what. I think this one was for defining a stack of instrument 
combinations. There was also a file for saving impulse response samples for 
GigaPulse, I think those were .gsp files, but we are not supporting them 
either.

Andreas might tell you more about the unsupported GSt file types.

CU
Christian

[Linuxsampler-devel] [linuxsampler-devel] "Cannot load file: Unknown leverage controller type"

[Andrew C <cou...@gm...>]

I cannot load the Eb Clarinet long notes giga file from Westgate Studios
into Linuxsampler.

I get the error "Cannot load file: Unknown leverage controller type".

Now the gig file, according to its manual, has some fancy imidi/GigaStudio
specific scripting for Legato which I thought I could see if I could get
working with gigedit... But this error appeared.

There are also .gsi files inside the directory relating to Legato, but I
don't think they're supported by linuxsampler at this time?

Andrew.

Re: [Linuxsampler-devel] [OT?] Linuxsampler DSSI setup

[Andrew C <cou...@gm...>]

Thanks for the heads up guys!

Rosegarden's omni midi routing for dssi was one of my biggest issues with
it. :P

Tried Muse and it gets two points in favour of switching: one being the
same name as one of my favourite bands and the other that it can do
"multi-channel" for one instance. Neat stuff and I'm sold on Muse now.

--

On a LinuxSampler-related note, I need some advice WRT Jsampler and
stability.

If I open JSampler after playing a bunch of notes, or at the same time as
I'm playing notes, Linuxsampler crashes after JSampler opens up or LS
crashes with the JSampler box displaying 'Applying global voice limits' or
some such.

LSCPServer: Client connection terminated on socket:9.
LSCPServer: Client connection terminated on socket:4.
LSCPServer: Client connection established on socket:4.
LSCPServer: Client connection established on socket:9.
Pool::resizePool() ERROR: elements still in use!
Segmentation fault (core dumped)

This happens to LS both standalone and running as a DSSI inside of RG/Muse.

Andrew.

On Thu, May 18, 2017 at 10:20 AM, Luis Garrido <
lui...@us...> wrote:

> On 17/05/17 20:53, Andrew C wrote:
>
> >>The usual work flow with any plugin standard I know of, is usually one
> >>(instrument) plugin instance per DAW track.
>
> You might want to give a try to ls16, an alternate DSSI LinuxSampler
> adapter. Perhaps it will suit your workflow better:
>
> https://sourceforge.net/p/ls16/wiki/Home/
>
> However, there is no workaround for Rosegarden's omni MIDI routing
> model. Perhaps have a look at QTractor or MusE?
>
>
> Regards,
>
> L
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] [OT?] Linuxsampler DSSI setup

[Luis G. <lui...@us...>]

On 17/05/17 20:53, Andrew C wrote:

>>The usual work flow with any plugin standard I know of, is usually one
>>(instrument) plugin instance per DAW track.

You might want to give a try to ls16, an alternate DSSI LinuxSampler 
adapter. Perhaps it will suit your workflow better:

https://sourceforge.net/p/ls16/wiki/Home/

However, there is no workaround for Rosegarden's omni MIDI routing 
model. Perhaps have a look at QTractor or MusE?


Regards,

L

Re: [Linuxsampler-devel] [OT?] Linuxsampler DSSI setup

[Christian S. <sch...@li...>]

On Wednesday, May 17, 2017 21:30:09 Andrew C wrote:
> So if I have one midi input port for the linuxsampler instance, I can,
> using qsampler, simply add extra channel strips and create 'layered' sounds
> for that particular port.
> 
> Midi Port 0: Violins, Cellos, Violas, Basses sustain patches loaded up (In
> Linuxsampler) -> Linuxsampler.so instance #1(in Rosegarden)  - > "Full
> Strings" sequencer track
> 
> Midi Port 1: Maestro Grand v2 patch loaded up (In Linuxsampler) ->
> Linuxsampler.so instance #2(in Rosegarden)  - > "Piano" sequencer track
> 
> ... and so on?

Correct.

> After that, I'm just limited by the number of plugins my sequencer can let
> me load and don't even need to care about what midi channel goes where?

Well, for the "layered sounds" scenario you don't need to care about MIDI 
channels. Just make sure the manually created sampler parts (i.e. the ones 
added with QSampler) are set to listen to "all" MIDI channels.

For the 2nd scenario with only one sound (piano) you don't have to take care 
about MIDI channels either.

But since your problem is the limited amount of tracks in Rosegarden, I guess 
you might also have a different scenario one day where you have a Rosegarden 
track which contains MIDI data for multiple different target sounds, so that 
track would have MIDI data for multiple different MIDI channels. And in that 
particular scenario you would of course need to take care about the MIDI 
channel setup inside the sampler.

CU
Christian

Re: [Linuxsampler-devel] [OT?] Linuxsampler DSSI setup

[Andrew C <cou...@gm...>]

Thank you so much for the indepth response, Christian! I was a bit slow on
the uptake of the design workflow here with plugins...
Did some more RTFMing and googling to make sense of it.

>What I must add here, and maybe that's the missing brick for you to solve
that
>issue: Even when using the plugin version of the sampler you can still add
as
>many sampler parts (channel strips) as you want on their own i.e. with
>QSampler. So you don't need to add a new plugin instance just to add a new
>sampler part.

Yes, this makes it crystal clear.

So if I have one midi input port for the linuxsampler instance, I can,
using qsampler, simply add extra channel strips and create 'layered' sounds
for that particular port.

Midi Port 0: Violins, Cellos, Violas, Basses sustain patches loaded up (In
Linuxsampler) -> Linuxsampler.so instance #1(in Rosegarden)  - > "Full
Strings" sequencer track

Midi Port 1: Maestro Grand v2 patch loaded up (In Linuxsampler) ->
Linuxsampler.so instance #2(in Rosegarden)  - > "Piano" sequencer track

... and so on?

After that, I'm just limited by the number of plugins my sequencer can let
me load and don't even need to care about what midi channel goes where?


On Wed, May 17, 2017 at 8:49 PM, Christian Schoenebeck <
sch...@li...> wrote:

> On Wednesday, May 17, 2017 21:28:09 Christian Schoenebeck wrote:
> > For the small minority of users [ you ;-) ] who want a different plugin
> > behavior: Like I said, simply launch your plugin instances, then open
> > QSampler and modify the sampler internal MIDI routing as desired. So you
> > can also hook up several sampler parts (a.k.a. channel strips in
> QSampler)
> > to one MIDI input port of your plugin instances, and also the other way
> > around, one sampler part (channel strip) to several MIDI input ports. And
> > then select for each sampler part a specific MIDI channel and that's it.
>
> What I must add here, and maybe that's the missing brick for you to solve
> that
> issue: Even when using the plugin version of the sampler you can still add
> as
> many sampler parts (channel strips) as you want on their own i.e. with
> QSampler. So you don't need to add a new plugin instance just to add a new
> sampler part.
>
> Does this make it more clear?
>
> CU
> Christian
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] [OT?] Linuxsampler DSSI setup

[Christian S. <sch...@li...>]

On Wednesday, May 17, 2017 21:28:09 Christian Schoenebeck wrote:
> For the small minority of users [ you ;-) ] who want a different plugin
> behavior: Like I said, simply launch your plugin instances, then open
> QSampler and modify the sampler internal MIDI routing as desired. So you
> can also hook up several sampler parts (a.k.a. channel strips in QSampler)
> to one MIDI input port of your plugin instances, and also the other way
> around, one sampler part (channel strip) to several MIDI input ports. And
> then select for each sampler part a specific MIDI channel and that's it.

What I must add here, and maybe that's the missing brick for you to solve that 
issue: Even when using the plugin version of the sampler you can still add as 
many sampler parts (channel strips) as you want on their own i.e. with 
QSampler. So you don't need to add a new plugin instance just to add a new 
sampler part.

Does this make it more clear?

CU
Christian

Re: [Linuxsampler-devel] [OT?] Linuxsampler DSSI setup

[Christian S. <sch...@li...>]

On Wednesday, May 17, 2017 19:53:03 Andrew C wrote:
> Rosegarden does not support LV2, sadly. I think it is on the developers'
> 'to do' list Soon(tm).
> 
> >The usual work flow with any plugin standard I know of, is usually one
> >(instrument) plugin instance per DAW track.
> 
> Yes, I seem to be barking up the wrong tree at the wrong people.
> AFAICS, LinuxSampler creates a new midi port and instrument for each plugin
> instance with the midi channel set to (all), as opposed to simply using the
> same midi port and using the next available channel for the new instrument.

Yes, because that's the desired (default) behavior for the majority of all DAW 
plugin users. Like I said, no matter which DAW and plugin standard you are 
using, nowadays you create a separate DAW track for each sound. Which has the 
advantage that you don't have to worry about MIDI channels at all, which would 
be error prone.

And in fact, I realized that more and more younger people are not even aware 
about what a "MIDI channel" is, due to that circumstance.

> I was expecting the latter functionality, but I suspect this is an "issue"
> with Rosegarden, as opposed to LinuxSampler.*

Which is not a problem. What I described is the default behavior for 
LinuxSampler. When you launch plugin instances, they appear to the sampler as 
separate MIDI ports. But nobody forces you to use them.

For the small minority of users [ you ;-) ] who want a different plugin 
behavior: Like I said, simply launch your plugin instances, then open QSampler 
and modify the sampler internal MIDI routing as desired. So you can also hook 
up several sampler parts (a.k.a. channel strips in QSampler) to one MIDI input 
port of your plugin instances, and also the other way around, one sampler part 
(channel strip) to several MIDI input ports. And then select for each sampler 
part a specific MIDI channel and that's it.

Then when you save your song, the entire sampler setup will automatically be 
stored with your DAW song file and vice versa; the entire sampler setup will 
automatically be restored when you load your song in your DAW again
[ok, at least if Rosegarden supports state saving of plugins].

CU
Christian

Re: [Linuxsampler-devel] [OT?] Linuxsampler DSSI setup

[Andrew C <cou...@gm...>]

Rosegarden does not support LV2, sadly. I think it is on the developers'
'to do' list Soon(tm).

>The usual work flow with any plugin standard I know of, is usually one
>(instrument) plugin instance per DAW track.

Yes, I seem to be barking up the wrong tree at the wrong people.
AFAICS, LinuxSampler creates a new midi port and instrument for each plugin
instance with the midi channel set to (all), as opposed to simply using the
same midi port and using the next available channel for the new instrument.

I was expecting the latter functionality, but I suspect this is an "issue"
with Rosegarden, as opposed to LinuxSampler.*

*Not really an issue, but as mentioned, with RG's 24 hardcoded plugin
instance limit with no "true"(?) multi-timbral support, it seems that using
LS/FluidSynth as standalone instruments is the way to go for multi-channel
goodness.

This post is rambling a bit... :P


On Wed, May 17, 2017 at 5:14 PM, Christian Schoenebeck <
sch...@li...> wrote:

> On Tuesday, May 16, 2017 11:17:07 Andrew C wrote:
> > Not sure if I should post this here or to LAU, but here goes.
>
> Don't worry, there is not much traffic around here.
>
> > Finally I've decided to step into the modern age of plugins running in
> > hosts as opposed to having everything standalone and hooking up endless
> > midi channels in qjackctl.
> >
> > I'm kind of having difficulty wrapping my head around how it all works,
> so
> > I'll try and simplify my question to a one-liner:
> >
> > Can I assign multiple midi channels to a single linuxsampler plugin
> > instance? Or does DSSI work with one plugin per channel?
>
> The usual work flow with any plugin standard I know of, is usually one
> (instrument) plugin instance per DAW track.
>
> DSSI is actually the predecessor of LV2. So most people use LV2 or VST on
> Linux. Does Rosegarden not support LV2?
>
> > My host (Rosegarden) has a seemingly hard-coded 24 available slots to put
> > dssi plugins into, so having access to all 16 channels from one plugin
> > instance would be great, but maybe this entirely outside the scope of how
> > dssi works?
>
> All plugin standards are sending their MIDI data with a MIDI channel,
> including DSSI. So after you created your DSSI plugin instances you can
> adjust
> your overall setup i.e. with QSampler for your needs. So yes, you can do
> that.
>
> CU
> Christian
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] [OT?] Linuxsampler DSSI setup

[Christian S. <sch...@li...>]

On Tuesday, May 16, 2017 11:17:07 Andrew C wrote:
> Not sure if I should post this here or to LAU, but here goes.

Don't worry, there is not much traffic around here.

> Finally I've decided to step into the modern age of plugins running in
> hosts as opposed to having everything standalone and hooking up endless
> midi channels in qjackctl.
> 
> I'm kind of having difficulty wrapping my head around how it all works, so
> I'll try and simplify my question to a one-liner:
> 
> Can I assign multiple midi channels to a single linuxsampler plugin
> instance? Or does DSSI work with one plugin per channel?

The usual work flow with any plugin standard I know of, is usually one 
(instrument) plugin instance per DAW track.

DSSI is actually the predecessor of LV2. So most people use LV2 or VST on 
Linux. Does Rosegarden not support LV2?

> My host (Rosegarden) has a seemingly hard-coded 24 available slots to put
> dssi plugins into, so having access to all 16 channels from one plugin
> instance would be great, but maybe this entirely outside the scope of how
> dssi works?

All plugin standards are sending their MIDI data with a MIDI channel, 
including DSSI. So after you created your DSSI plugin instances you can adjust 
your overall setup i.e. with QSampler for your needs. So yes, you can do that.

CU
Christian

[Linuxsampler-devel] [OT?] Linuxsampler DSSI setup

[Andrew C <cou...@gm...>]

Not sure if I should post this here or to LAU, but here goes.

Finally I've decided to step into the modern age of plugins running in
hosts as opposed to having everything standalone and hooking up endless
midi channels in qjackctl.

I'm kind of having difficulty wrapping my head around how it all works, so
I'll try and simplify my question to a one-liner:

Can I assign multiple midi channels to a single linuxsampler plugin
instance? Or does DSSI work with one plugin per channel?

My host (Rosegarden) has a seemingly hard-coded 24 available slots to put
dssi plugins into, so having access to all 16 channels from one plugin
instance would be great, but maybe this entirely outside the scope of how
dssi works?

Andrew.

[Linuxsampler-devel] new gigedit features

[Christian S. <sch...@li...>]

On Sunday, May 14, 2017 17:09:33 Andrew C wrote:
> Thanks, Christian! Got all the bits and pieces finally working in unison.
> Took me a bit of googling to figure out I had to install linuxsampler
> before I installed gigedit so I could live edit, but it all works now!
> 
> I should make a new post for this, but I'm really digging the new features
> of gigedit since I last saw it. I'm looking forward to digging into it
> (Though considering .gig is more or less 'dead', manually editing .sfz
> files isn't my cup of tea....).
> 
> What kind of scripting language is used in gigedit? I see there is a
> 'script's feature.

One question, one link: :)

	http://doc.linuxsampler.org/Instrument_Scripts/NKSP_Language/

Adding, writing and assigning scripts to instruments with gigedit:

	http://doc.linuxsampler.org/Gigedit/Managing_Scripts/

Current state of gigedit's built-in script editor:

	http://doc.linuxsampler.org/News/Instrument_Script_Editor_2016-05-04/

CU
Christian

Re: [Linuxsampler-devel] LibGIg Compiler error on UbuntuStudio 16.04

[Andrew C <cou...@gm...>]

Thanks, Christian! Got all the bits and pieces finally working in unison.
Took me a bit of googling to figure out I had to install linuxsampler
before I installed gigedit so I could live edit, but it all works now!

I should make a new post for this, but I'm really digging the new features
of gigedit since I last saw it. I'm looking forward to digging into it
(Though considering .gig is more or less 'dead', manually editing .sfz
files isn't my cup of tea....).

What kind of scripting language is used in gigedit? I see there is a
'script's feature.

On Sun, May 14, 2017 at 2:24 PM, Christian Schoenebeck <
sch...@li...> wrote:

> On Sunday, May 14, 2017 11:55:19 Andrew C wrote:
> > UbuntuStudio must be "unique" in this regard...
> >
> > Got another compile time error, if you'd like to take a look :D
> >
> > mainwindow.cpp: In member function ‘void Saver::thread_function()’:
> > mainwindow.cpp:1215:156: error: ‘String’ was not declared in this scope
> >   temporary file (unable to remove original file): " +
> > String(strerror(errno)));
>
> Try again.
>
> I think I got the idea what the cause of all these errors now is. Seems
> GCC 5
> became more strict on typedefs.
>
> CU
> Christian
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] LibGIg Compiler error on UbuntuStudio 16.04

[Christian S. <sch...@li...>]

On Sunday, May 14, 2017 11:55:19 Andrew C wrote:
> UbuntuStudio must be "unique" in this regard...
> 
> Got another compile time error, if you'd like to take a look :D
> 
> mainwindow.cpp: In member function ‘void Saver::thread_function()’:
> mainwindow.cpp:1215:156: error: ‘String’ was not declared in this scope
>   temporary file (unable to remove original file): " +
> String(strerror(errno)));

Try again.

I think I got the idea what the cause of all these errors now is. Seems GCC 5 
became more strict on typedefs.

CU
Christian

Re: [Linuxsampler-devel] LibGIg Compiler error on UbuntuStudio 16.04

[Andrew C <cou...@gm...>]

UbuntuStudio must be "unique" in this regard...

Got another compile time error, if you'd like to take a look :D

mainwindow.cpp: In member function ‘void Saver::thread_function()’:
mainwindow.cpp:1215:156: error: ‘String’ was not declared in this scope
  temporary file (unable to remove original file): " +
String(strerror(errno)));

^
mainwindow.cpp:1215:156: note: suggested alternatives:
In file included from /usr/local/include/libgig/DLS.h:27:0,
                 from /usr/local/include/libgig/gig.h:27,
                 from global.h:49,
                 from mainwindow.cpp:47:
/usr/local/include/libgig/RIFF.h:144:25: note:   ‘RIFF::String’
     typedef std::string String;
                         ^
In file included from /usr/local/include/libgig/gig.h:27:0,
                 from global.h:49,
                 from mainwindow.cpp:47:
/usr/local/include/libgig/DLS.h:106:25: note:   ‘DLS::String’
     typedef std::string String;
                         ^
In file included from global.h:50:0,
                 from mainwindow.cpp:47:
/usr/local/include/libgig/Serialization.h:119:25: note:
‘Serialization::String’
     typedef std::string String;
                         ^
In file included from global.h:49:0,
                 from mainwindow.cpp:47:
/usr/local/include/libgig/gig.h:94:25: note:   ‘gig::String’
     typedef std::string String;
                         ^
mainwindow.cpp:1222:152: error: ‘String’ was not declared in this scope
 with temporary file (unable to rename temp file): " +
String(strerror(errno)));

^
mainwindow.cpp:1222:152: note: suggested alternatives:
In file included from /usr/local/include/libgig/DLS.h:27:0,
                 from /usr/local/include/libgig/gig.h:27,
                 from global.h:49,
                 from mainwindow.cpp:47:
/usr/local/include/libgig/RIFF.h:144:25: note:   ‘RIFF::String’
     typedef std::string String;
                         ^
In file included from /usr/local/include/libgig/gig.h:27:0,
                 from global.h:49,
                 from mainwindow.cpp:47:
/usr/local/include/libgig/DLS.h:106:25: note:   ‘DLS::String’
     typedef std::string String;
                         ^
In file included from global.h:50:0,
                 from mainwindow.cpp:47:
/usr/local/include/libgig/Serialization.h:119:25: note:
‘Serialization::String’
     typedef std::string String;
                         ^
In file included from global.h:49:0,
                 from mainwindow.cpp:47:
/usr/local/include/libgig/gig.h:94:25: note:   ‘gig::String’
     typedef std::string String;
                         ^
Makefile:733: recipe for target 'libgigedit_la-mainwindow.lo' failed
make[4]: *** [libgigedit_la-mainwindow.lo] Error 1
make[4]: Leaving directory
'/home/andrew/Desktop/Linuxsampler/gigedit/src/gigedit'



On Sat, May 13, 2017 at 8:02 PM, Christian Schoenebeck <
sch...@li...> wrote:

> On Friday, May 12, 2017 20:51:44 Andrew C wrote:
> > One final thing re svn gigedit now :>
> >
> > Got the following when trying to compile it:
> >
> > mainwindow.cpp: In member function ‘void Saver::thread_function()’:
> > mainwindow.cpp:1207:17: error: ‘String’ was not declared in this scope
> >                  String tmpname = filename + ".TMP";
> >                  ^
>
> I have no idea why this error triggered with your compiler and not with any
> one in our compiler arsenal, but ooookaaay.
>
> I just committed a fix to SVN. Should work now for you.
>
> CU
> Christian
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] LibGIg Compiler error on UbuntuStudio 16.04

[Christian S. <sch...@li...>]

On Friday, May 12, 2017 20:51:44 Andrew C wrote:
> One final thing re svn gigedit now :>
> 
> Got the following when trying to compile it:
> 
> mainwindow.cpp: In member function ‘void Saver::thread_function()’:
> mainwindow.cpp:1207:17: error: ‘String’ was not declared in this scope
>                  String tmpname = filename + ".TMP";
>                  ^

I have no idea why this error triggered with your compiler and not with any 
one in our compiler arsenal, but ooookaaay.

I just committed a fix to SVN. Should work now for you.

CU
Christian

Re: [Linuxsampler-devel] LibGIg Compiler error on UbuntuStudio 16.04

[Andrew C <cou...@gm...>]

One final thing re svn gigedit now :>

Got the following when trying to compile it:

mainwindow.cpp: In member function ‘void Saver::thread_function()’:
mainwindow.cpp:1207:17: error: ‘String’ was not declared in this scope
                 String tmpname = filename + ".TMP";
                 ^
mainwindow.cpp:1207:17: note: suggested alternatives:
In file included from /usr/local/include/libgig/DLS.h:27:0,
                 from /usr/local/include/libgig/gig.h:27,
                 from global.h:49,
                 from mainwindow.cpp:47:
/usr/local/include/libgig/RIFF.h:144:25: note:   ‘RIFF::String’
     typedef std::string String;
                         ^
In file included from /usr/local/include/libgig/gig.h:27:0,
                 from global.h:49,
                 from mainwindow.cpp:47:
/usr/local/include/libgig/DLS.h:106:25: note:   ‘DLS::String’
     typedef std::string String;
                         ^
In file included from global.h:50:0,
                 from mainwindow.cpp:47:
/usr/local/include/libgig/Serialization.h:119:25: note:
‘Serialization::String’
     typedef std::string String;
                         ^
In file included from global.h:49:0,
                 from mainwindow.cpp:47:
/usr/local/include/libgig/gig.h:94:25: note:   ‘gig::String’
     typedef std::string String;
                         ^
mainwindow.cpp:1208:27: error: ‘tmpname’ was not declared in this scope
                 gig->Save(tmpname, &progress);
                           ^
Makefile:721: recipe for target 'libgigedit_la-mainwindow.lo' failed
make[4]: *** [libgigedit_la-mainwindow.lo] Error 1
make[4]: Leaving directory
'/home/ubuntu-studio/Desktop/Linuxsampler/gigedit/src/gigedit'


On Fri, May 12, 2017 at 8:07 PM, Andrew C <cou...@gm...> wrote:

> Thanks, using 'make parser' worked fine and linuxsampler builds properly.
>
> On Fri, May 12, 2017 at 12:53 PM, Christian Schoenebeck <
> sch...@li...> wrote:
>
>> On Friday, May 12, 2017 11:59:57 Andrew C wrote:
>> > Thanks, Christian, that works like a charm. Libgig compiled
>> successfully.
>> >
>> > Getting a makefile/make related error now when trying to build
>> Linuxsampler
>> > from SVN:
>> >
>> [snip]
>> > make[3]: Entering directory
>> > '/home/ubuntu-studio/Desktop/Linuxsampler/linuxsampler/src/scriptvm'
>> > make[3]: *** No rule to make target 'parser.h', needed by 'all'.  Stop.
>>
>> Make sure bison is installed on your machine, then try this:
>>
>>         cd TOPLEVELDIROFLSSOURCES
>>         make parser
>>         make
>>
>> If that does not do it, then make a clean rebuild instead:
>>
>>         cd TOPLEVELDIROFLSSOURCES
>>         make -f Makefile.svn clean
>>         make -f Makefile.svn
>>         ./configure
>>         make
>>
>> Since you are using a Debian flavored distro, you can of course also build
>> .deb packages instead:
>>
>>         cd TOPLEVELDIROFLSSOURCES
>>         dpkg-buildpackage -b
>>
>> And then install the built .deb packages:
>>
>>         dpkg -i REPLACE_BY_DEB_FILES
>>
>> There is also a (fairly old) Debian howto:
>>
>>         http://linuxsampler.org/debian.html
>>
>> CU
>> Christian
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Linuxsampler-devel mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>>
>
>

Re: [Linuxsampler-devel] LibGIg Compiler error on UbuntuStudio 16.04

[Andrew C <cou...@gm...>]

Thanks, using 'make parser' worked fine and linuxsampler builds properly.

On Fri, May 12, 2017 at 12:53 PM, Christian Schoenebeck <
sch...@li...> wrote:

> On Friday, May 12, 2017 11:59:57 Andrew C wrote:
> > Thanks, Christian, that works like a charm. Libgig compiled successfully.
> >
> > Getting a makefile/make related error now when trying to build
> Linuxsampler
> > from SVN:
> >
> [snip]
> > make[3]: Entering directory
> > '/home/ubuntu-studio/Desktop/Linuxsampler/linuxsampler/src/scriptvm'
> > make[3]: *** No rule to make target 'parser.h', needed by 'all'.  Stop.
>
> Make sure bison is installed on your machine, then try this:
>
>         cd TOPLEVELDIROFLSSOURCES
>         make parser
>         make
>
> If that does not do it, then make a clean rebuild instead:
>
>         cd TOPLEVELDIROFLSSOURCES
>         make -f Makefile.svn clean
>         make -f Makefile.svn
>         ./configure
>         make
>
> Since you are using a Debian flavored distro, you can of course also build
> .deb packages instead:
>
>         cd TOPLEVELDIROFLSSOURCES
>         dpkg-buildpackage -b
>
> And then install the built .deb packages:
>
>         dpkg -i REPLACE_BY_DEB_FILES
>
> There is also a (fairly old) Debian howto:
>
>         http://linuxsampler.org/debian.html
>
> CU
> Christian
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] LibGIg Compiler error on UbuntuStudio 16.04

[Christian S. <sch...@li...>]

On Friday, May 12, 2017 11:59:57 Andrew C wrote:
> Thanks, Christian, that works like a charm. Libgig compiled successfully.
> 
> Getting a makefile/make related error now when trying to build Linuxsampler
> from SVN:
> 
[snip]
> make[3]: Entering directory
> '/home/ubuntu-studio/Desktop/Linuxsampler/linuxsampler/src/scriptvm'
> make[3]: *** No rule to make target 'parser.h', needed by 'all'.  Stop.

Make sure bison is installed on your machine, then try this:

	cd TOPLEVELDIROFLSSOURCES
	make parser
	make

If that does not do it, then make a clean rebuild instead:

	cd TOPLEVELDIROFLSSOURCES
	make -f Makefile.svn clean
	make -f Makefile.svn
	./configure
	make

Since you are using a Debian flavored distro, you can of course also build 
.deb packages instead:

	cd TOPLEVELDIROFLSSOURCES
	dpkg-buildpackage -b

And then install the built .deb packages:

	dpkg -i REPLACE_BY_DEB_FILES

There is also a (fairly old) Debian howto:

	http://linuxsampler.org/debian.html

CU
Christian

Re: [Linuxsampler-devel] LibGIg Compiler error on UbuntuStudio 16.04

[Andrew C <cou...@gm...>]

Thanks, Christian, that works like a charm. Libgig compiled successfully.

Getting a makefile/make related error now when trying to build Linuxsampler
from SVN:

make  all-recursive
make[1]: Entering directory
'/home/ubuntu-studio/Desktop/Linuxsampler/linuxsampler'
Making all in man
make[2]: Entering directory
'/home/ubuntu-studio/Desktop/Linuxsampler/linuxsampler/man'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory
'/home/ubuntu-studio/Desktop/Linuxsampler/linuxsampler/man'
Making all in src
make[2]: Entering directory
'/home/ubuntu-studio/Desktop/Linuxsampler/linuxsampler/src'
Making all in scriptvm
make[3]: Entering directory
'/home/ubuntu-studio/Desktop/Linuxsampler/linuxsampler/src/scriptvm'
make[3]: *** No rule to make target 'parser.h', needed by 'all'.  Stop.
make[3]: Leaving directory
'/home/ubuntu-studio/Desktop/Linuxsampler/linuxsampler/src/scriptvm'
Makefile:689: recipe for target 'all-recursive' failed


On Thu, May 11, 2017 at 11:13 PM, Christian Schoenebeck <
sch...@li...> wrote:

> On Thursday, May 11, 2017 19:07:25 Andrew C wrote:
> > P.S. This is from the latest libgig svn.
> >
> > Andrew.
> >
> > On Thu, May 11, 2017 at 7:04 PM, Andrew C <cou...@gm...>
> wrote:
> > > Hey guys,
> > >
> > > I'm trying to compile Libgig on UbuntuStudio 16.04 and I'm getting a
> > > compile time error.
> > >
> > > Here's the version of g++ i'm using:
> > >
> > > g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
> > >
> [snip]
> > >
> > > In file included from gig.cpp:27:0:
> > > Serialization.h: In function ‘bool Serialization::IsClass(const T&)’:
> > > Serialization.h:138:16: error: ‘__is_union_or_class’ is not a member of
> > > ‘std::tr1’>
> > >          return std::tr1::__is_union_or_class<T>::value; // without
> > >          compiler sup
> > >
> > >                 ^
>
> I just commited something to SVN which should fix this error. Hope it
> works.
>
> CU
> Christian
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] LibGIg Compiler error on UbuntuStudio 16.04

[Christian S. <sch...@li...>]

On Thursday, May 11, 2017 19:07:25 Andrew C wrote:
> P.S. This is from the latest libgig svn.
> 
> Andrew.
> 
> On Thu, May 11, 2017 at 7:04 PM, Andrew C <cou...@gm...> wrote:
> > Hey guys,
> > 
> > I'm trying to compile Libgig on UbuntuStudio 16.04 and I'm getting a
> > compile time error.
> > 
> > Here's the version of g++ i'm using:
> > 
> > g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
> > 
[snip]
> > 
> > In file included from gig.cpp:27:0:
> > Serialization.h: In function ‘bool Serialization::IsClass(const T&)’:
> > Serialization.h:138:16: error: ‘__is_union_or_class’ is not a member of
> > ‘std::tr1’> 
> >          return std::tr1::__is_union_or_class<T>::value; // without
> >          compiler sup
> >          
> >                 ^

I just commited something to SVN which should fix this error. Hope it works.

CU
Christian

Re: [Linuxsampler-devel] LibGIg Compiler error on UbuntuStudio 16.04

[Andrew C <cou...@gm...>]

P.S. This is from the latest libgig svn.

Andrew.

On Thu, May 11, 2017 at 7:04 PM, Andrew C <cou...@gm...> wrote:

> Hey guys,
>
> I'm trying to compile Libgig on UbuntuStudio 16.04 and I'm getting a
> compile time error.
>
> Here's the version of g++ i'm using:
>
> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>
> Thanks in advance, guys :)
>
>
> Andrew.
>
> ---
>
> Here's the error messages:
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -pedantic -Wreturn-type -g -O2 -MT gig.lo -MD -MP -MF .deps/gig.Tpo -c gig.cpp  -fPIC -DPIC -o .libs/gig.o
> In file included from gig.cpp:24:0:
> gig.h:85:33: warning: anonymous variadic macros were introduced in C++11 [-Wvariadic-macros]
>  # define GIG_DECLARE_ENUM(type, ...) enum type { __VA_ARGS__ }
>                                  ^
> In file included from gig.cpp:27:0:
> Serialization.h: In function ‘bool Serialization::IsClass(const T&)’:
> Serialization.h:138:16: error: ‘__is_union_or_class’ is not a member of ‘std::tr1’
>          return std::tr1::__is_union_or_class<T>::value; // without compiler sup
>                 ^
> Serialization.h:138:47: error: expected primary-expression before ‘>’ token
>          return std::tr1::__is_union_or_class<T>::value; // without compiler sup
>                                                ^
> Serialization.h:138:48: error: ‘::value’ has not been declared
>          return std::tr1::__is_union_or_class<T>::value; // without compiler sup
>                                                 ^
> Serialization.h: At global scope:
> Serialization.h:40:32: error: ‘__is_union_or_class’ is not a member of ‘std::tr1’
>  # define LIBGIG_IS_CLASS(type) std::tr1::__is_union_or_class<type>::value //NOT
>                                 ^
> Serialization.h:700:71: note: in expansion of macro ‘LIBGIG_IS_CLASS’
>        struct SerializationRecursion : SerializationRecursionImpl<T, LIBGIG_IS_C
>                                                                      ^
> Serialization.h:40:32: error: ‘__is_union_or_class’ is not a member of ‘std::tr1’
>  # define LIBGIG_IS_CLASS(type) std::tr1::__is_union_or_class<type>::value //NOT
>                                 ^
> Serialization.h:700:71: note: in expansion of macro ‘LIBGIG_IS_CLASS’
>        struct SerializationRecursion : SerializationRecursionImpl<T, LIBGIG_IS_C
>                                                                      ^
> Serialization.h:40:66: error: template argument 2 is invalid
>  # define LIBGIG_IS_CLASS(type) std::tr1::__is_union_or_class<type>::value //NOT
>                                                                   ^
> Serialization.h:700:71: note: in expansion of macro ‘LIBGIG_IS_CLASS’
>        struct SerializationRecursion : SerializationRecursionImpl<T, LIBGIG_IS_C
>                                                                      ^
> Serialization.h:40:67: error: expected ‘{’ before ‘::’ token
>  # define LIBGIG_IS_CLASS(type) std::tr1::__is_union_or_class<type>::value //NOT
>                                                                    ^
> Serialization.h:700:71: note: in expansion of macro ‘LIBGIG_IS_CLASS’
>        struct SerializationRecursion : SerializationRecursionImpl<T, LIBGIG_IS_C
>                                                                      ^
> Serialization.h:700:89: error: expected initializer before ‘>’ token
>  ct SerializationRecursion : SerializationRecursionImpl<T, LIBGIG_IS_CLASS(T)> {
>                                                                              ^
> Serialization.h:701:10: warning: extra ‘;’ [-Wpedantic]
>          };
>           ^
> Serialization.h: In instantiation of ‘void Serialization::Archive::serializeMember(const T_classType&, const T_memberType&, const char*) [with T_classType = gig::leverage_ctrl_t; T_memberType = gig::leverage_ctrl_t::type_t]’:
> gig.cpp:326:9:   required from here
> Serialization.h:605:70: error: incomplete type ‘Serialization::Archive::SerializationRecursion<gig::leverage_ctrl_t::type_t>’ used in nested name specifier
>                 SerializationRecursion<T_memberType>::serializeObject(this, nati
>                                                                      ^
> Serialization.h: In instantiation of ‘void Serialization::Archive::serializeMember(const T_classType&, const T_memberType&, const char*) [with T_classType = gig::leverage_ctrl_t; T_memberType = unsigned int]’:
> gig.cpp:327:9:   required from here
> Serialization.h:605:70: error: incomplete type ‘Serialization::Archive::SerializationRecursion<unsigned int>’ used in nested name specifier
> Serialization.h: In instantiation of ‘void Serialization::Archive::serializeMember(const T_classType&, const T_memberType&, const char*) [with T_classType = gig::crossfade_t; T_memberType = unsigned char]’:
> gig.cpp:336:9:   required from here
> Serialization.h:605:70: error: incomplete type ‘Serialization::Archive::SerializationRecursion<unsigned char>’ used in nested name specifier
> Serialization.h: In instantiation of ‘void Serialization::Archive::serializeMember(const T_classType&, const T_memberType&, const char*) [with T_classType = gig::DimensionRegion; T_memberType = unsigned char]’:
> gig.cpp:1820:9:   required from here
> Serialization.h:605:70: error: incomplete type ‘Serialization::Archive::SerializationRecursion<unsigned char>’ used in nested name specifier
> Serialization.h: In instantiation of ‘void Serialization::Archive::serializeMember(const T_classType&, const T_memberType&, const char*) [with T_classType = gig::DimensionRegion; T_memberType = short unsigned int]’:
> gig.cpp:1821:9:   required from here
>
>

[Linuxsampler-devel] LibGIg Compiler error on UbuntuStudio 16.04

[Andrew C <cou...@gm...>]

Hey guys,

I'm trying to compile Libgig on UbuntuStudio 16.04 and I'm getting a
compile time error.

Here's the version of g++ i'm using:

g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

Thanks in advance, guys :)


Andrew.

---

Here's the error messages:
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -pedantic
-Wreturn-type -g -O2 -MT gig.lo -MD -MP -MF .deps/gig.Tpo -c gig.cpp
-fPIC -DPIC -o .libs/gig.o
In file included from gig.cpp:24:0:
gig.h:85:33: warning: anonymous variadic macros were introduced in
C++11 [-Wvariadic-macros]
 # define GIG_DECLARE_ENUM(type, ...) enum type { __VA_ARGS__ }
                                 ^
In file included from gig.cpp:27:0:
Serialization.h: In function ‘bool Serialization::IsClass(const T&)’:
Serialization.h:138:16: error: ‘__is_union_or_class’ is not a member
of ‘std::tr1’
         return std::tr1::__is_union_or_class<T>::value; // without compiler sup
                ^
Serialization.h:138:47: error: expected primary-expression before ‘>’ token
         return std::tr1::__is_union_or_class<T>::value; // without compiler sup
                                               ^
Serialization.h:138:48: error: ‘::value’ has not been declared
         return std::tr1::__is_union_or_class<T>::value; // without compiler sup
                                                ^
Serialization.h: At global scope:
Serialization.h:40:32: error: ‘__is_union_or_class’ is not a member of
‘std::tr1’
 # define LIBGIG_IS_CLASS(type) std::tr1::__is_union_or_class<type>::value //NOT
                                ^
Serialization.h:700:71: note: in expansion of macro ‘LIBGIG_IS_CLASS’
       struct SerializationRecursion : SerializationRecursionImpl<T, LIBGIG_IS_C
                                                                     ^
Serialization.h:40:32: error: ‘__is_union_or_class’ is not a member of
‘std::tr1’
 # define LIBGIG_IS_CLASS(type) std::tr1::__is_union_or_class<type>::value //NOT
                                ^
Serialization.h:700:71: note: in expansion of macro ‘LIBGIG_IS_CLASS’
       struct SerializationRecursion : SerializationRecursionImpl<T, LIBGIG_IS_C
                                                                     ^
Serialization.h:40:66: error: template argument 2 is invalid
 # define LIBGIG_IS_CLASS(type) std::tr1::__is_union_or_class<type>::value //NOT
                                                                  ^
Serialization.h:700:71: note: in expansion of macro ‘LIBGIG_IS_CLASS’
       struct SerializationRecursion : SerializationRecursionImpl<T, LIBGIG_IS_C
                                                                     ^
Serialization.h:40:67: error: expected ‘{’ before ‘::’ token
 # define LIBGIG_IS_CLASS(type) std::tr1::__is_union_or_class<type>::value //NOT
                                                                   ^
Serialization.h:700:71: note: in expansion of macro ‘LIBGIG_IS_CLASS’
       struct SerializationRecursion : SerializationRecursionImpl<T, LIBGIG_IS_C
                                                                     ^
Serialization.h:700:89: error: expected initializer before ‘>’ token
 ct SerializationRecursion : SerializationRecursionImpl<T, LIBGIG_IS_CLASS(T)> {
                                                                             ^
Serialization.h:701:10: warning: extra ‘;’ [-Wpedantic]
         };
          ^
Serialization.h: In instantiation of ‘void
Serialization::Archive::serializeMember(const T_classType&, const
T_memberType&, const char*) [with T_classType = gig::leverage_ctrl_t;
T_memberType = gig::leverage_ctrl_t::type_t]’:
gig.cpp:326:9:   required from here
Serialization.h:605:70: error: incomplete type
‘Serialization::Archive::SerializationRecursion<gig::leverage_ctrl_t::type_t>’
used in nested name specifier
                SerializationRecursion<T_memberType>::serializeObject(this, nati
                                                                     ^
Serialization.h: In instantiation of ‘void
Serialization::Archive::serializeMember(const T_classType&, const
T_memberType&, const char*) [with T_classType = gig::leverage_ctrl_t;
T_memberType = unsigned int]’:
gig.cpp:327:9:   required from here
Serialization.h:605:70: error: incomplete type
‘Serialization::Archive::SerializationRecursion<unsigned int>’ used in
nested name specifier
Serialization.h: In instantiation of ‘void
Serialization::Archive::serializeMember(const T_classType&, const
T_memberType&, const char*) [with T_classType = gig::crossfade_t;
T_memberType = unsigned char]’:
gig.cpp:336:9:   required from here
Serialization.h:605:70: error: incomplete type
‘Serialization::Archive::SerializationRecursion<unsigned char>’ used
in nested name specifier
Serialization.h: In instantiation of ‘void
Serialization::Archive::serializeMember(const T_classType&, const
T_memberType&, const char*) [with T_classType = gig::DimensionRegion;
T_memberType = unsigned char]’:
gig.cpp:1820:9:   required from here
Serialization.h:605:70: error: incomplete type
‘Serialization::Archive::SerializationRecursion<unsigned char>’ used
in nested name specifier
Serialization.h: In instantiation of ‘void
Serialization::Archive::serializeMember(const T_classType&, const
T_memberType&, const char*) [with T_classType = gig::DimensionRegion;
T_memberType = short unsigned int]’:
gig.cpp:1821:9:   required from here