Menu
▾
▴
linuxsampler-devel
|
From: Ivan M. <iv...@ma...> - 2019-02-09 22:16:02
Attachments:
libgig-4.1.0.svn8-multi_part_load_save.patch
|
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 except a .gx99 file if present. The presence of a 'DOXF' chunk indicates that a .gx99 extension file should be present on disk and the chunk itself provides the expected dlsid. The addition of this code enables correct Save and Save As of multi-part gig files (those with extension files: .gx01, .gx02 etc.). It also simplifies the way that multi-part .gig files are loaded. I have tested multi-part .gig files as well as ordinary 32-bit offset .gig files saved with this patch applied in GSEdit3 and GStdio3 and they load and play as expected. I haven't tested the changes with a library consisting of a single .gig file which uses 64-bit offsets as I don't have any of those to hand. There shouldn't be any change for files that don't have extension files though. All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-02-12 13:29:29
|
On Samstag, 9. Februar 2019 21:59:59 CET Ivan Maguidhir wrote: > Hi all, Hi Ivan, > I'm just writing to submit this patch that I've been working on / > testing for the last while. So far I haven't had the time to look at your patch thoroughly yet, but here some questions ... > 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 except a .gx99 > file if present. The presence of a 'DOXF' chunk indicates that a .gx99 > extension file should be present on disk and the chunk itself provides > the expected dlsid. Are those chunk types also used by GSt or have you introduced them? If you have introduced them, what are the precise reasons for introducing them? > I have tested multi-part .gig files as well as ordinary 32-bit offset > .gig files saved with this patch applied in GSEdit3 and GStdio3 and they > load and play as expected. I haven't tested the changes with a library > consisting of a single .gig file which uses 64-bit offsets as I don't > have any of those to hand. There shouldn't be any change for files that > don't have extension files though. GSt never supported gig files with 64 bit RIFF file offsets. I introduced that feature to allow writing gig files larger than 4 GB witht libgig, as one large gig file without extension files that is: http://doc.linuxsampler.org/Release_Notes/LinuxSampler_2_1_0/#libgig_4_1_0 Having said that, I currently wonder how to expose those two saving options to the API appropriately. My first thought was that mixing both 64 bit offsets with extension files does not make sense and that it should be thus an either or. That is if a gig file already uses extension files then it would obviously save changes distributed over extension files by using all 32 bit offsets, otherwise if somebody creates a new gig file from scratch with libgig then only when explicitly picking offset_size_32bit would cause extension files to be written. But on second thought, using both 64 bit and extensions files at the same time might be beneficial to split out certain aspects of a gig file intentionally to separate files while at the same time retaining things in large files. For instance what I could imagine is storing all samples of one sample group to the same file and distributing the individual sample groups over individual files.. That way sound designers could gain an option to create libraries in a more modular approach if desired, which is already standard with almost any other mordern sound library file format. CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-02-13 02:27:36
|
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 the precise reasons for introducing them? Yes, these chunk types are used by GSt. I figured out their structure by looking at gig files in a hex editor, some guesswork and modifying of libgig and testing its output in the GSt3 editor and main GSt3 application. I made little text diagrams showing the structure of the chunks as well, but I thought including them in the source code might be a bit over-the-top :-) > GSt never supported gig files with 64 bit RIFF file offsets. I introduced that > feature to allow writing gig files larger than 4 GB witht libgig, as one large > gig file without extension files that is: > > http://doc.linuxsampler.org/Release_Notes/LinuxSampler_2_1_0/#libgig_4_1_0 Sorry about that. I didn't realize 64-bit offsets were an extension. I was also thinking of the combined use of WavePoolTable and WavePoolTableHi, where WavePoolTableHi stores the extension file number, as being a 64-bit offset when it isn't really. > Having said that, I currently wonder how to expose those two saving options to > the API appropriately. My first thought was that mixing both 64 bit offsets > with extension files does not make sense and that it should be thus an either > or. That is if a gig file already uses extension files then it would obviously > save changes distributed over extension files by using all 32 bit offsets, This is all that the patch allows - the saving of existing libraries which use extension files to the same or a new location. > otherwise if somebody creates a new gig file from scratch with libgig then only > when explicitly picking offset_size_32bit would cause extension files to be > written. I'm going to have a go at implementing this next. > But on second thought, using both 64 bit and extensions files at the same time > might be beneficial to split out certain aspects of a gig file intentionally to > separate files while at the same time retaining things in large files. For > instance what I could imagine is storing all samples of one sample group to > the same file and distributing the individual sample groups over individual > files.. That way sound designers could gain an option to create libraries in a > more modular approach if desired, which is already standard with almost any > other mordern sound library file format. A solution might be to add an offset_size_32bit option to gigedit, as you suggested, which would cause the writing of extension files. In addition to this an "Extension Files" tab could be added to the left-hand pane in gigedit. This tab could contain a TreeView which would be inactive while offset_size_32bit was checked, with each 2GB extension file visible. Otherwise, users would be allowed to create and manage extension files of arbitrary size (but with a fixed offset size of 64-bits) using the TreeView. Content could then be assigned to the created extension files from the other tabs and pages. A new chunk similar to the official 'xfil' chunk could be added to the main gig to list these extension files. Does that sound like it's workable? > CU > Christian > All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-02-13 15:31:11
|
On Mittwoch, 13. Februar 2019 02:27:22 CET Ivan Maguidhir wrote: > > Are those chunk types also used by GSt or have you introduced them? If you > > have introduced them, what are the precise reasons for introducing them? > > Yes, these chunk types are used by GSt. I figured out their structure by > looking at gig files in a hex editor, some guesswork and modifying of > libgig and testing its output in the GSt3 editor and main GSt3 > application. I made little text diagrams showing the structure of the > chunks as well, but I thought including them in the source code might be > a bit over-the-top :-) 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? > > But on second thought, using both 64 bit and extensions files at the same > > time might be beneficial to split out certain aspects of a gig file > > intentionally to separate files while at the same time retaining things > > in large files. For instance what I could imagine is storing all samples > > of one sample group to the same file and distributing the individual > > sample groups over individual files.. That way sound designers could gain > > an option to create libraries in a more modular approach if desired, > > which is already standard with almost any other mordern sound library > > file format. > > A solution might be to add an offset_size_32bit option to gigedit, as > you suggested, which would cause the writing of extension files. In Yep, that was also my idea. > addition to this an "Extension Files" tab could be added to the > left-hand pane in gigedit. This tab could contain a TreeView which would > be inactive while offset_size_32bit was checked, with each 2GB extension > file visible. Otherwise, users would be allowed to create and manage > extension files of arbitrary size (but with a fixed offset size of > 64-bits) using the TreeView. Content could then be assigned to the > created extension files from the other tabs and pages. A new chunk > similar to the official 'xfil' chunk could be added to the main gig to > list these extension files. Does that sound like it's workable? Yes, it goes into the direction I thought about as well. But let's postpone any code for that custom 64-bit extension file feature for the moment and let's just finish the 32-bit GSt extension file feature for now. Because I still want to think about that custom 64-bit extension files feature for a while, since I want it not only to be powerful but also very user friendly. There are some aspects that should be designed appropriately right from the start without having to rewrite everything in libgig, LS and gigedit after a month or so. For instance I would like individual extension files to be sharable among different (main) gig files. If all those individual gig files are probably in separate directories (for instance think about a large directory tree with shared multi samples), then there should be some kind of support for relative paths or something. And that's where things can easily become tricky for not becoming a nightmare for users. Another thing is that adding an extension file in gigedit should be a quick and easy feature. I like the idea of having a 4th tab for showing all extension files, but yet people should also not being forced to make a dozent of clicks and keyboard entries just to create and assign one new extension file. CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-02-13 18:00:17
|
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 series of 144 byte records containing a filename string, the file extension repeated and a dlsid. The doxf chunk contains a 32-bit integer, a string and a dlsid. The libraries with extension files that I tested all had this integer set to '99' which I think corresponds to the .gx99 file extension. And yet changing this to different values and renaming the extension file accordingly doesn't produce output that GSt3 can open. The string also appears redundant as changing it or 'zeroing' it has no discernible effect in the GSt3 editor or main app. Its contents don't appear in the GSt3 editor File Info dialog either. So in my patch LS doesn't change anything except the dlsid in the doxf chunk. > Yes, it goes into the direction I thought about as well. But let's postpone > any code for that custom 64-bit extension file feature for the moment and let's > just finish the 32-bit GSt extension file feature for now. Because I still want > to think about that custom 64-bit extension files feature for a while, since I > want it not only to be powerful but also very user friendly. There are some > aspects that should be designed appropriately right from the start without > having to rewrite everything in libgig, LS and gigedit after a month or so. Agreed. I'll make a start on getting libgig to create 32-bit GSt extension files. > For instance I would like individual extension files to be sharable among > different (main) gig files. If all those individual gig files are probably in > separate directories (for instance think about a large directory tree with > shared multi samples), then there should be some kind of support for relative > paths or something. And that's where things can easily become tricky for not > becoming a nightmare for users. Yes. Support for relative paths would be good. I was thinking of relative paths recently when wondering how to detect the user calling "Save As..." on the same gig file so that libgig could call "Save" instead. > Another thing is that adding an extension file in gigedit should be a quick and > easy feature. I like the idea of having a 4th tab for showing all extension > files, but yet people should also not being forced to make a dozent of clicks > and keyboard entries just to create and assign one new extension file. The Drag & Drop that is used for assigning samples is great. I wonder if something similar could be used for assigning content to extension files? I'll have to think about it more though. > CU > Christian > All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-02-14 16:00:34
|
On Mittwoch, 13. Februar 2019 18:00:00 CET Ivan Maguidhir wrote:
> produce output that GSt3 can open. The string also appears redundant as
> changing it or 'zeroing' it has no discernible effect in the GSt3 editor
> or main app. Its contents don't appear in the GSt3 editor File Info
> dialog either. So in my patch LS doesn't change anything except the
> dlsid in the doxf chunk.
Yeah, there are numerous similar strange things in the gig format. :)
> Yes. Support for relative paths would be good. I was thinking of
> relative paths recently when wondering how to detect the user calling
> "Save As..." on the same gig file so that libgig could call "Save" instead.
That requires some more low-levelish trick. Basically that is done by
retrieving the inode number of two files you want to compare with. If the inode
number is identical (even though having different files names or path) then the
files are actually identical.
So far I haven't done that yet, because that code is system dependent and
sometimes even file system type dependent, so it would need to be implemented
for them individually. But maybe we could start by adding code for the most
popular ones, and the other one would still get the old warning when selecting
Save as ...
Also note that term "inode" is usually used by Linux file systems like
ext2/3/4, other file systems use a different term, even though the concept is
mostly the same.
> The Drag & Drop that is used for assigning samples is great. I wonder if
> something similar could be used for assigning content to extension
> files? I'll have to think about it more though.
Would be an option, sure. But I still wonder at which point things should be
possible to be assigned to extension files at first place. At the moment I think
I would probably restrict to assign content to extension files on
a) {sample group} and
b) {instrument} level.
That could already be sufficient I think.
Allowing to assign also individual samples or even dimension regions or
something to extension files would probably be overkill and I think not worth
the hassle.
And for instrument scripts this could also either be done on script group
level or, other possibility: *only* automatically, in the latter case libgig
would rather auto detect which exported instrument references some script and
automatically export the script as well. Both solutions have pros and cons.
But these are just some thoughts for now ...
CU
Christian
|
|
From: Ivan M. <iv...@ma...> - 2019-02-20 02:04:51
Attachments:
gigedit.jpg
|
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 properties dialog. All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-02-20 12:36:32
|
On Mittwoch, 20. Februar 2019 02:04:19 CET Ivan Maguidhir wrote: > 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 > properties dialog. Please share your design ideas before implementing anything to avoid substantial code rewrites later on. For example looking at your screen shot, I don't think that setting a maximum file size for extension files is necessary at all. I think the GSt way of saving extension files (.gx01, .gx02, ... , .gx99) should only be used for saving gig files intended to be compatible with the GigaStudio software, and in that case the max. files size would be always 2GB anyway. For the more flexible approach (not intended to be compatible with GigaStudio) that we recently discussed, I do have other plans: for instance it would not use the .gxYY scheme at all, most notably because I want those extension files to have a) any name, not just the same base name as main gig file, and b) I want those extension files to be loadable from different directories than the main gig file in order to allow sharing individual extension files among multiple main gig files. Please also note that I am currently adjusting your previous libgig patch for allowing to save also with a different amount of extension files. So keep that in mind to avoid we two are working on the same thing. I expect to commit these libgig changes in the next couple hours. CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-02-20 16:38:45
|
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 files is necessary at all. I think the GSt way of saving > extension files (.gx01, .gx02, ... , .gx99) should only be used for saving gig > files intended to be compatible with the GigaStudio software, and in that case > the max. files size would be always 2GB anyway. The changes I've made to gigedit and libgig are only for creating Gigastudio compatible extension files. I included the max file size setting only because it's there in the GSt3 save dialog. As you correctly point out no one would really need to change this value. The default setting in the GSt3 editor is 2040. I think this is in mebibytes. My idea was to add/remove extension files as samples are being added/removed instead of doing all the work of splitting the .gig up during a File::Save(). > For the more flexible approach (not intended to be compatible with GigaStudio) > that we recently discussed, I do have other plans: for instance it would not > use the .gxYY scheme at all, most notably because I want those extension files > to have a) any name, not just the same base name as main gig file, and > b) I want those extension files to be loadable from different directories than > the main gig file in order to allow sharing individual extension files among > multiple main gig files. That sounds great. > Please also note that I am currently adjusting your previous libgig patch for > allowing to save also with a different amount of extension files. So keep that > in mind to avoid we two are working on the same thing. I expect to commit > these libgig changes in the next couple hours. Many thanks for doing that. > CU > Christian All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-02-20 16:57:21
|
On Mittwoch, 20. Februar 2019 16:38:31 CET Ivan Maguidhir wrote: > 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. 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 the new chunks (see below). These were the adjustments I made regarding your patch: 1. Moved out all file path parsing code as helper functions, instead of doing those string parsing tasks directly in the file saving / loading methods. and more importantly: 2. I tried to generalize your code more in order to also allow to save gigs with any different amount of extension files. So it is now also valid to remove or add extension files without getting an exception when eventually trying to save it. But there is still some work to do for my changes in (2.) for becoming actually useful; most importantly when saving a gig file, the samples should automatically be (re)assigned over individual extension files and accordingly also the amount of extension files should automatically be increased or decreased accordingly. I have no plans in the next days or so to do that though. I will process the MSVC patch next. 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 convolution effect data (a.k.a. GigaPulse). So now that makes more sense why that is always handled separately as .gx99. > > For example looking at your screen shot, I don't think that setting a > > maximum file size for extension files is necessary at all. I think the > > GSt way of saving extension files (.gx01, .gx02, ... , .gx99) should only > > be used for saving gig files intended to be compatible with the > > GigaStudio software, and in that case the max. files size would be always > > 2GB anyway. > > The changes I've made to gigedit and libgig are only for creating > Gigastudio compatible extension files. I included the max file size > setting only because it's there in the GSt3 save dialog. As you Ah, interesting, I see. Ok, then fine, I did not know that. My knowledge was that GigaStudio would always simply distribute over 2GB files when saving. I did not know there was an option to change the individual file size. > correctly point out no one would really need to change this value. The > default setting in the GSt3 editor is 2040. I think this is in > mebibytes. My idea was to add/remove extension files as samples are > being added/removed instead of doing all the work of splitting the .gig > up during a File::Save(). So I would suggest simply adding two checkboxes to gigedit's file format dialog: - "Large File Support" (default on) - "GigaStudio Legacy Extension Files" (default off) And if you want you can also preserve your individual file size setting of course. And when "GigaStudio Legacy Extension Files" is turned on, then "Large File Support" is automatically turned off and vice versa. So there would only be 3 possibilities: 1. Large File On, Legacy Ext. Off 2. Large File Off, Legacy Ext. Off 3. Large File Off, Legacy Ext. On And later on (not yet now), I would add a third checkbox e.g. "Next Gen. Extension Files (incompatible with GigaStudio)" with the more fancy way of modularizing parts of a gig file, like we discussed recently and hopefully will discuss in more detail soon. > > Please also note that I am currently adjusting your previous libgig patch > > for allowing to save also with a different amount of extension files. So > > keep that in mind to avoid we two are working on the same thing. I expect > > to commit these libgig changes in the next couple hours. > > Many thanks for doing that. Thanks for your patch Ivan! CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-02-20 18:04:06
|
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 the new chunks (see below). No problem. I'll do this this evening. > 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? Yes that's exactly right. 4 byte int containing '99', string zero padded to 128 bytes and 16 byte dlsid. > And I also figured out now what this ominous ".gx99" file is about: that's for > writing convolution effect data (a.k.a. GigaPulse). So now that makes more > sense why that is always handled separately as .gx99. That's great! I think this means that the string in the 'doxf' chunk might actually be an impulse name. I wonder also if the .gx99 file is just a RIFF file with a .gsi (Gigastudio Impulse) file embedded in it? I have several of both of these types of file to hand so I'll try to figure out if this is the case. It would be nice to know the .gsi file structure also in order to add reverb at some point in the future. > So I would suggest simply adding two checkboxes to gigedit's file format > dialog: > > - "Large File Support" (default on) > - "GigaStudio Legacy Extension Files" (default off) > That makes sense. I'll do that. > Thanks for your patch Ivan! You're more than welcome! > CU > Christian > All the best, Ivan |
|
From: Ivan M. <iv...@ma...> - 2019-02-20 20:28:15
|
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 convolution effect data (a.k.a. GigaPulse). So now that makes more > sense why that is always handled separately as .gx99. Hi Christian, Further to my message earlier, I had a look at two libraries I have containing .gx99 files again and in both .gig files the 'doxf' chunk's string contains the filename of the .gx99 file. Which disproves my theory about it being an impulse name. In some other libraries I have it contains the name of a file which no longer exists (the original gig filename before being renamed probably). So I think my initial assumption that the string is unused is correct. All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-02-21 17:23:40
|
On Mittwoch, 20. Februar 2019 20:27:53 CET Ivan Maguidhir wrote: > Further to my message earlier, I had a look at two libraries I have > containing .gx99 files again and in both .gig files the 'doxf' chunk's > string contains the filename of the .gx99 file. Which disproves my > theory about it being an impulse name. In some other libraries I have it > contains the name of a file which no longer exists (the original gig > filename before being renamed probably). So I think my initial > assumption that the string is unused is correct. 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 without its associated .gx99 file, a “No Banks Found” error message will be displayed upon loading the instrument. Always be sure to keep .gx99 files together with their .gig files." CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-02-22 22:26:31
Attachments:
libgig-4.1.0.svn14-smallfixes.patch
|
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 without > its associated .gx99 file, a “No Banks Found” error message will > be displayed upon loading the instrument. Always be sure to keep > .gx99 files together with their .gig files." Yeah, there is very little information on them. I'll try creating some gig libraries which result in a .gx99 file being created using the GSt3 editor to see what different outputs I get. I don't know how to create instruments from scratch yet though, so I have a bit of studying to do! I've attached a patch containing a few small corrections to the changes you made when integrating my patch. > CU > Christian > All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-02-22 23:59:16
|
On Freitag, 22. Februar 2019 22:26:18 CET Ivan Maguidhir wrote: > 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 without > > > > its associated .gx99 file, a “No Banks Found” error message > > will > > be displayed upon loading the instrument. Always be sure to keep > > > > .gx99 files together with their .gig files." > > Yeah, there is very little information on them. I'll try creating some > gig libraries which result in a .gx99 file being created using the GSt3 > editor to see what different outputs I get. I don't know how to create > instruments from scratch yet though, so I have a bit of studying to do! First steps on that are the hardest ones. If you got questions, just ask. > I've attached a patch containing a few small corrections to the changes > you made when integrating my patch. Oops, sorry and thanks! There are still some issues with the helper functions with certain paths. I grab some sleep and then I fix the rest of the helper function issues during the day. CU Christian |
|
From: Christian S. <sch...@li...> - 2019-02-23 15:46:12
|
On Samstag, 23. Februar 2019 00:58:46 CET Christian Schoenebeck wrote: > > I've attached a patch containing a few small corrections to the changes > > you made when integrating my patch. > > Oops, sorry and thanks! There are still some issues with the helper > functions with certain paths. I grab some sleep and then I fix the rest of > the helper function issues during the day. Ok, committed the fixes (SVN r3483). I also added test cases against those helper functions: cd src/testcases/ g++ HelperTest.cpp ./a.out CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-02-23 16:43:31
|
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 |
Thanks for helping keep SourceForge clean.
X