Hi Christian
On 19/01/2020 21:20, Christian Schoenebeck wrote:
Hi Ivan,
I just realized now your patch probably does not what you wanted it to:
http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/gig.cpp?
r1=3656&r2=3655&pathrev=3656
You see the problem?
Nothing jumped out at me
Hi Christian
On 19/12/2019 12:39, Christian Schoenebeck wrote:
Let's postpone that. I won't have the time to check that file soon. We'll keep
an eye on this issue, and if it really happens again we'll take closer look.
No problem. I'll keep the instrument in case we need it later.
So what d
On 15/12/2019 20:59, Ivan Maguidhir wrote:
Interestingly, the '3ddp' chunk is only written by GSEdit and never
read. Which makes me think it's only of use to GSt when playing
instruments for effects or the mixer (or something similar) as the
'3ddp' values seem to
On 15/12/2019 13:34, Christian Schoenebeck wrote:
In gig v1 even. I can't remember having seen those chunks before with GSt < 3
files. But if it really turns out that these chunks were always there, then we
can still change that of course and add them for all gig file format versions.
In my TO
Hi Christian
On 14/12/2019 17:26, Christian Schoenebeck wrote:
Ok, I just committed 2 parts of your patch. I committed your 128 '3gnm' chunks
patch unmodified:
http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=3656
Thanks!
Regarding the '3dnm' and '3ddp' chunks: I moved tha
On 13/12/2019 13:40, Christian Schoenebeck wrote:
Nice job! :)
Give me some time, I probably have to make some minor adjustments to your
patch.
Thanks!
No problem. I'm glad it's helpful. I'll take a look at the GSt3 crash
that happens with newly created gigedit instruments next.
CU
Christi
Hi Christian
On 11/12/2019 12:30, Christian Schoenebeck wrote:
Hmm... I wonder what GSt actually expects on gig file level if no loop was
enabled. I mean it's probably not a big deal if GSt spits out a warning on
such gig files, but would be nice to have if fixed on libgig side if
reasonable.
Hi Christian
On 10/12/2019 10:25, Christian Schoenebeck wrote:
Maybe it's really just the loop setting that made the difference there.
Because that indeed causes a data structure change.
Yes, you're right. I created an instrument from scratch again with
gigedit. Without Loops enabled I get the
Hi Christian
On 08/12/2019 19:05, Christian Schoenebeck wrote:
Does that mean we can leave the current chunk names for our gig format
extensions? So after you changed the chunk names you got the exact same
behaviour as yesterday?
Yes. GSEdit3 displays the 'protected' message even when I creat
Hi Christian
On 08/12/2019 09:51, Christian Schoenebeck wrote:
Ivan, you could check your assumption and replace the defines for our own
chunk names, namely LIST_TYPE_3LS and LIST_TYPE_RTIS in src/gig.h by something
else.
I think Andreas is right. On modifying the chunk IDs for LIST_TYPE_3LS
Hi Christian
I get the following behaviour in GSEdit3 using the new gain option:
Gain of -96 to 0dB in gigedit => Attenuation of 0 to 96dB, 6dB boost set
to '0 - No' in GSEdit
Gain of 6dB in gigedit => Attenuation of 0dB, 6dB boost set to '1 - Yes'
in GSEdit
Gain > than 0dB other than 6dB => A
Hi Christian
Many thanks for the reply earlier!
On 20/10/2019 16:18, Christian Schoenebeck wrote:
Well, since we support both gtk3 and gtk2, and since there are no plans to
drop gtk2 support, it was good to know though that there was an gtk2 issue.
That's great that both will be supported goin
Hi Christian
Whoops. It was my fault, I didn't have the gtk3-devel package installed.
The configure script now detects gtk3 properly.
All the best,
Ivan
___
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sou
Hi Christian
On 16/10/2019 19:02, Christian Schoenebeck wrote:
I just wonder why it did not work there on your machine. For me it worked
before both on Linux as well as on Mac, so I wonder what's the difference.
Are you still using Gtk2?
Yes, that was it. I'm using Fedora 30 and I have both gtk
Hi Christian
I was missing some changes from my linuxsampler patch earlier. I've
attached an updated one.
All the best,
Ivan
diff -Naur linuxsampler_orig/src/engines/common/AbstractVoice.cpp linuxsampler_mod/src/engines/common/AbstractVoice.cpp
--- linuxsampler_orig/src/engines/common/Abstrac
Hi Christian
I really like the graphical render of the LFO settings! The attached
gigedit patch connects all of the LFO controls to queue_draw() so that
the graphic gets redrawn while the user is making changes to any of them.
I noticed while I was using gigedit that the range for Control Dep
On 29/09/2019 11:17, Christian Schoenebeck wrote:
Ok then I guess I'll change that in our gig engine to:
* LFO1 (volume): mid start level
* LFO2 (cutoff): mid start level
* LFO3 (pitch): max start level
Sounds good. Thanks Christian.
unless somebody has objections.
On 28/09/2019 12:51, Christian Schoenebeck wrote:
Thanks!
No problem.
I looked and listened to your audio files.
As for LFO1: it seems you were right, according to your audio demo file it
seems as if LFO1 starts with a mid value (instead of a max value that we
currently have in our implementa
On 27/09/2019 20:25, Christian Schoenebeck wrote:
That way you should clearly hear the difference whether the amp LFO starts
with max. volume or mid value volume.
For LFO 2 and LFO 3 you would do the same steps.
Hi Christian
I've updated the wave files I linked to earlier. Of course they we
On 27/09/2019 20:25, Christian Schoenebeck wrote:
Hmm, sounds not very reliable for this issue.
Yes, you're right.
That way you should clearly hear the difference whether the amp LFO starts
with max. volume or mid value volume.
For LFO 2 and LFO 3 you would do the same steps.
Thanks a mi
On 27/09/2019 10:12, Christian Schoenebeck wrote:
That graphic in the GSt editor might as well just be some symbolic
representation of the LFO wave form, or does the graphic of the LFO function
change when you alter any parameter?
Yes, the wavelength of the waveform representing the LFO in the
On 26/09/2019 14:32, Christian Schoenebeck wrote:
Hi all,
Hi Christian,
I was reviewing our gig engine's LFO code and noticed that their behaviour
does not match with GigaStudio's original LFO behaviour. So I planned to
change that:
1. Our gig engine is using triangle LFOs whereas it looks
On 23/02/2019 15:45, Christian Schoenebeck wrote:
Ok, committed the fixes (SVN r3483).
I also added test cases against those helper functions:
cd src/testcases/
g++ HelperTest.cpp
./a.out
Many thanks Christian.
CU
Christian
All the best,
Ivan
___
On 21/02/2019 17:23, Christian Schoenebeck wrote:
I can't say. I just googled "gx99 file" and I see various independent source
that this file was about "GigaPulse settings". One of them is a PDF from
Tascam, quote:
"If convolution encoded instrument is copied onto a GS3 system
witho
On 20/02/2019 16:57, Christian Schoenebeck wrote:
Also note in DLS.cpp, where it is now automatically creating the 'doxf' chunk
if missing, I was assuming a chunk size of 148 bytes. Is that correct?
And I also figured out now what this ominous ".gx99" file is about: that's for
writing convolut
On 20/02/2019 16:57, Christian Schoenebeck wrote:
Ok, I just committed the libgig changes for writing gig extension files (SVN
r3474). Please review and test them, because most nostably I do not have any
gigs with extension files so I cannot test it, and I am also missing some
knowledge about t
On 20/02/2019 12:36, Christian Schoenebeck wrote:
Please share your design ideas before implementing anything to avoid
substantial code rewrites later on.
Sorry about that. I will in future.
For example looking at your screen shot, I don't think that setting a maximum
file size for extension
Hi Christian
I should have a patch to allow the creation of extension files within a
day or two. I think I have a solution already but I want to test it by
creating a few instruments from scratch and trying them out in LS and
GSt3. I've attached a screen grab of my changes to the gigedit file
On 13/02/2019 15:30, Christian Schoenebeck wrote:
Ah I see, great!
Does that mean you even explored more information/features in those new GSt
chunks than currently covered by your patch so far?
No. There isn't that much in them. The xfil chunk consists of a 32-bit
count, followed by a serie
On 12/02/2019 13:29, Christian Schoenebeck wrote:
Hi Ivan,
Hi Christian
So far I haven't had the time to look at your patch thoroughly yet, but here
some questions ...
No problem at all.
Are those chunk types also used by GSt or have you introduced them? If you
have introduced them, what are
Hi all,
I'm just writing to submit this patch that I've been working on /
testing for the last while.
The patch provides code for reading and updating 'XFIL' and 'DOXF'
chunks during load and save operations. The 'XFIL' chunk gives the
count, filenames and expected dlsids of extension files
Hi Christian
On 23/12/2018 23:18, Christian Schoenebeck wrote:
I also committed required changes to gigedit. You find a new combo box and a
new checkbox on the "Misc" tab there.
Didn't have the time to test these things. I'm off for couple days now;
Christmas obligations.
I just want to draw
On 23/12/2018 23:18, Christian Schoenebeck wrote:
Happy Christmas holidays guys, and don't drink too much! :)
Thanks Christian! The same to you.
___
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.ne
Hi Christian
On 23/12/2018 19:51, Christian Schoenebeck wrote:
On libgig side my intention was to only use one subchunk ("LSDE") for all
format extensions that we might introduce on DimensionRegion level.
That's a much better design! Brilliant, thanks!
It did occur to me to try this by giving t
Hi Christian
On 21/12/2018 19:54, Christian Schoenebeck wrote:
I am not assuming anything. That's the point. I am trying to understand what
the actual purpose of the file is and whether the proposed change is still
suboptimal, hence I am asking.
What I know about the .gx99 file is that it is par
Hi Christian
On 21/12/2018 10:32, Christian Schoenebeck wrote:
Ok, that is one side of the coin. But usually all extension files are also
mentioned in the main gig file, or to be more precise, their precise extension
file number is stored in the upper (hi) wave table entry. And this is not the
c
Hi Christian
On 20/12/2018 23:30, Christian Schoenebeck wrote:
You have libraries where you only have two files like foo.gig and foo.gx99 ?
Sounds very odd to me.
The Tascam GigaPiano II instrument, from the GigaStudio3 installation
CDs, that I mentioned earlier actually has this structure. It
Hi
I've attached an updated version of the linuxsampler-2.1.0.svn1 patch I
submitted on Tuesday morning.
The previous one should have worked most of the time but the logic
wasn't quite correct. I'm using copies of Tascam GigaPiano II, edited in
gigedit, to test my changes btw and they appear t
Hi Christian and everyone
On 14/12/2018 12:08, Christian Schoenebeck wrote:
Well, that already a great step! Most of our valueable GSt infos we got were
by using the GSt instrument editor.
However when the limit is still 2000 then I don't understand why you got the
sample offset problem at firs
No problem at all Jaime. Glad to hear it will help!
On 13/12/2018 09:19, Jaime T wrote:
I have exactly the same problem with the original Gigapiano. I haven't
had a chance to try out your fix yet, but thank you for finding this!
(The problem makes linuxsampler unusable with that instrument).
Hi Christian
On 13/12/2018 13:23, Christian Schoenebeck wrote:
You think the USB dongle is the problem? I guess you are just passing through
the USB dongle for direct acess to the Virtualbox guest OS, that works usually
quite well due to its simplicity. Maybe there is rather a problem with the
G
Hi Christian
On 10/12/2018 14:53, Christian Schoenebeck wrote:
On Sonntag, 9. Dezember 2018 19:39:23 CET Ivan Maguidhir wrote:
That makes sense. What does gigdump print as global file information for a
gig v4 file?
Here's a link to a zip file containing dumps of all the GSt4 instru
On 09/12/2018 11:59, Christian Schoenebeck wrote:
On Samstag, 8. Dezember 2018 17:15:54 CET Ivan Maguidhir wrote:
Hi everyone
Hi Ivan!
Hi Christian. Thanks for the quick response.
libgig-4.1.0.svn5-load_giga4_as_giga3.patch causes GigaStudio 4
instruments to be loaded as if they were
Hi everyone
I've attached two small patches that I'm using that you might also find
useful.
linuxsampler-2.1.0.svn1-sustain_release_velocity.patch causes sustain
release samples to be played with the latest Note On velocity of each
key instead of the current hard-coded velocity of 127 (the h
44 matches
Mail list logo
