Menu
▾
▴
linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(27) |
Nov
(120) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(65) |
Feb
(2) |
Mar
(53) |
Apr
(15) |
May
|
Jun
(19) |
Jul
(8) |
Aug
(35) |
Sep
(17) |
Oct
(70) |
Nov
(87) |
Dec
(94) |
| 2004 |
Jan
(133) |
Feb
(28) |
Mar
(45) |
Apr
(30) |
May
(113) |
Jun
(132) |
Jul
(33) |
Aug
(29) |
Sep
(26) |
Oct
(11) |
Nov
(21) |
Dec
(60) |
| 2005 |
Jan
(108) |
Feb
(153) |
Mar
(108) |
Apr
(44) |
May
(72) |
Jun
(90) |
Jul
(99) |
Aug
(67) |
Sep
(117) |
Oct
(38) |
Nov
(40) |
Dec
(27) |
| 2006 |
Jan
(16) |
Feb
(18) |
Mar
(21) |
Apr
(71) |
May
(26) |
Jun
(48) |
Jul
(27) |
Aug
(40) |
Sep
(20) |
Oct
(118) |
Nov
(69) |
Dec
(35) |
| 2007 |
Jan
(76) |
Feb
(98) |
Mar
(26) |
Apr
(126) |
May
(94) |
Jun
(46) |
Jul
(9) |
Aug
(89) |
Sep
(18) |
Oct
(27) |
Nov
|
Dec
(49) |
| 2008 |
Jan
(117) |
Feb
(40) |
Mar
(18) |
Apr
(30) |
May
(40) |
Jun
(10) |
Jul
(30) |
Aug
(13) |
Sep
(29) |
Oct
(23) |
Nov
(22) |
Dec
(35) |
| 2009 |
Jan
(19) |
Feb
(39) |
Mar
(17) |
Apr
(2) |
May
(6) |
Jun
(6) |
Jul
(8) |
Aug
(11) |
Sep
(1) |
Oct
(46) |
Nov
(13) |
Dec
(5) |
| 2010 |
Jan
(21) |
Feb
(3) |
Mar
(2) |
Apr
(7) |
May
(1) |
Jun
(26) |
Jul
(3) |
Aug
(10) |
Sep
(13) |
Oct
(35) |
Nov
(10) |
Dec
(17) |
| 2011 |
Jan
(26) |
Feb
(27) |
Mar
(14) |
Apr
(32) |
May
(8) |
Jun
(11) |
Jul
(4) |
Aug
(7) |
Sep
(27) |
Oct
(25) |
Nov
(7) |
Dec
(2) |
| 2012 |
Jan
(20) |
Feb
(17) |
Mar
(59) |
Apr
(31) |
May
|
Jun
(6) |
Jul
(7) |
Aug
(10) |
Sep
(11) |
Oct
(2) |
Nov
(4) |
Dec
(17) |
| 2013 |
Jan
(17) |
Feb
(2) |
Mar
(3) |
Apr
(4) |
May
(8) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
| 2014 |
Jan
(6) |
Feb
(26) |
Mar
(12) |
Apr
(14) |
May
(8) |
Jun
(7) |
Jul
(6) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(9) |
Feb
(5) |
Mar
(4) |
Apr
(9) |
May
(3) |
Jun
(2) |
Jul
(4) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(3) |
| 2016 |
Jan
(2) |
Feb
(4) |
Mar
(5) |
Apr
(4) |
May
(14) |
Jun
(31) |
Jul
(18) |
Aug
|
Sep
(10) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
(39) |
Feb
(5) |
Mar
(2) |
Apr
|
May
(52) |
Jun
(11) |
Jul
(36) |
Aug
(1) |
Sep
(7) |
Oct
(4) |
Nov
(10) |
Dec
(8) |
| 2018 |
Jan
(3) |
Feb
(4) |
Mar
|
Apr
(8) |
May
(28) |
Jun
(11) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(25) |
| 2019 |
Jan
(12) |
Feb
(50) |
Mar
(14) |
Apr
(3) |
May
(8) |
Jun
(17) |
Jul
(10) |
Aug
(2) |
Sep
(21) |
Oct
(10) |
Nov
|
Dec
(28) |
| 2020 |
Jan
(4) |
Feb
(10) |
Mar
(7) |
Apr
(16) |
May
(10) |
Jun
(7) |
Jul
(2) |
Aug
(5) |
Sep
(3) |
Oct
(3) |
Nov
(2) |
Dec
(1) |
| 2021 |
Jan
|
Feb
(5) |
Mar
(13) |
Apr
(13) |
May
(7) |
Jun
|
Jul
(1) |
Aug
(11) |
Sep
(12) |
Oct
(7) |
Nov
(26) |
Dec
(41) |
| 2022 |
Jan
(23) |
Feb
|
Mar
(8) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(1) |
Dec
(1) |
| 2023 |
Jan
|
Feb
(5) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(11) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2024 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(10) |
Dec
|
| 2025 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(17) |
Jul
(1) |
Aug
(4) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
|
From: Doug G. <dou...@gm...> - 2021-09-28 05:38:43
|
Apologies for what may be a trivial question but I am un-accustomed to compiling the source but I have an error I'm not sure how to fix, see as follows. Note: This code was checked out today. # Add here commands to compile the package. /usr/bin/make make[1]: Entering directory '/home/pi/lssvn/linuxsampler' /usr/bin/make all-recursive make[2]: Entering directory '/home/pi/lssvn/linuxsampler' Making all in man make[3]: Entering directory '/home/pi/lssvn/linuxsampler/man' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/pi/lssvn/linuxsampler/man' Making all in src make[3]: Entering directory '/home/pi/lssvn/linuxsampler/src' Making all in scriptvm make[4]: Entering directory '/home/pi/lssvn/linuxsampler/src/scriptvm' make[4]: *** No rule to make target 'parser.h', needed by 'all'. Stop. I have looked but cannot see the solution. Also, to update the svn image I presume the command would be: svn up https://svn.linuxsampler.org/svn/linuxsampler/trunk linuxsampler Correct? TIA Doug Gray |
|
From: Kolja K. <ko...@fr...> - 2021-09-10 18:44:55
|
> > Well, there must be some note/velocity numbers info somewhere, either > in the > wav file (content) itself, or as part of the file name. For other use > cases > more options would need to be added to wav2gig, like a default value > for > velocity, note, ... if there is no match. > Yes, I thought so as well. My current idea is to patch your new regex in wav2gig (didn't look into it yet) and catch a case, where there is only a value instead a regex, at least for --regex-velocity-nr and --regex-note-nr. > > Another thing to > > mention is that the (mono-)files' last character show their stereo- > > position (L for left, R for right). > > Yeah, that's something that is supported in the korg2gig tool > already, but not > in wav2gig yet: > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/tools/korg2gig.cpp?revision=3175&view=markup#l232 Cool, thanks. By reading that, I just learned about gig2stereo. Didn't know that existed. I will definitely use that! > Well, like always, it's a long way to the top. :) > Yepp, and guess what you see, when you climbed "that last cliff"? :) > > Maybe I'm putting that on a github-site, have never done that > > before... > > Sure, why not. Ok, I'll do that and let you know. > But more cleanup would not really be negative. ;) Very nice phrasing! :] You're definitely right about that.... Cheers, Kolja > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Christian S. <sch...@li...> - 2021-09-10 15:41:06
|
On Mittwoch, 8. September 2021 19:27:49 CEST Kolja Koch wrote:
> Hi,
>
> thanks for the tipps!
>
> I made some progress, see attached screenshots.
>
> example1 shows processing the default-naming-scheme. I already renamed
> these files with my initial shell-script to that. When hitting OK, a
> wav2gig-command is created:
>
> wav2gig --regex-name1 "(.*) - .* - \d* - \d* - .* .*" --regex-name2 ".*
> - (.*) - \d* - \d* - .* .*" --regex-velocity-nr ".* - .* - (\d*) - \d*
> - .* .*" --regex-note-nr ".* - .* - \d* - (\d*) - .* .*" --regex-note-
> name ".* - .* - \d* - \d* - (.*) .*" [list of files]
>
> This actually worked! :)
>
> example2 however shows a much more complex case. As to see on the left,
> there are a lot of files in that folder and they don't have any note-
> number nor velocity. The tool will calculate the notenumbers based on
> given sign-characters (' ' for sharp in this case).
Well, there must be some note/velocity numbers info somewhere, either in the
wav file (content) itself, or as part of the file name. For other use cases
more options would need to be added to wav2gig, like a default value for
velocity, note, ... if there is no match.
> Another thing to
> mention is that the (mono-)files' last character show their stereo-
> position (L for left, R for right).
Yeah, that's something that is supported in the korg2gig tool already, but not
in wav2gig yet:
http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/tools/korg2gig.cpp?revision=3175&view=markup#l232
> So with the specifier-string one
> can enter in the middle of the window, this added to the corresponding
> name2 (%m appears twice). Also, not all files comply to the specifier-
> scheme, that's why I entered a second one, wich will be used against
> the remaining files. This way, all files could be processed, creating
> 18 gig files out of that. Theoretically, you can enter as many
> specifier-schemes as you like.
> Surely, this wouldn't actually work with wav2gig, since I don't know
> how to translate this into the required regex.
> Another thing is that there's no velocity given. Don't know, how
> wav2gig would react on this.
>
> I'm not absolutely sure, how to go on from now. The whole thing would
> need some cleanup, I'd like to implement some options, help and
> preferences. In order to implement the bottleneck from above I would
> have to patch wav2gig, I'm afraid. This wouldn't be something for your
> mainstream, thou, I guess.
Well, like always, it's a long way to the top. :)
> Maybe I'm putting that on a github-site, have never done that before...
Sure, why not. But more cleanup would not really be negative. ;)
CU
Christian
|
|
From: Kolja K. <ko...@fr...> - 2021-09-08 17:27:34
|
Hi,
thanks for the tipps!
I made some progress, see attached screenshots.
example1 shows processing the default-naming-scheme. I already renamed
these files with my initial shell-script to that. When hitting OK, a
wav2gig-command is created:
wav2gig --regex-name1 "(.*) - .* - \d* - \d* - .* .*" --regex-name2 ".*
- (.*) - \d* - \d* - .* .*" --regex-velocity-nr ".* - .* - (\d*) - \d*
- .* .*" --regex-note-nr ".* - .* - \d* - (\d*) - .* .*" --regex-note-
name ".* - .* - \d* - \d* - (.*) .*" [list of files]
This actually worked! :)
example2 however shows a much more complex case. As to see on the left,
there are a lot of files in that folder and they don't have any note-
number nor velocity. The tool will calculate the notenumbers based on
given sign-characters (' ' for sharp in this case). Another thing to
mention is that the (mono-)files' last character show their stereo-
position (L for left, R for right). So with the specifier-string one
can enter in the middle of the window, this added to the corresponding
name2 (%m appears twice). Also, not all files comply to the specifier-
scheme, that's why I entered a second one, wich will be used against
the remaining files. This way, all files could be processed, creating
18 gig files out of that. Theoretically, you can enter as many
specifier-schemes as you like.
Surely, this wouldn't actually work with wav2gig, since I don't know
how to translate this into the required regex.
Another thing is that there's no velocity given. Don't know, how
wav2gig would react on this.
I'm not absolutely sure, how to go on from now. The whole thing would
need some cleanup, I'd like to implement some options, help and
preferences. In order to implement the bottleneck from above I would
have to patch wav2gig, I'm afraid. This wouldn't be something for your
mainstream, thou, I guess.
Maybe I'm putting that on a github-site, have never done that before...
> Later on I will make that available by more convenient functions via
> > the
> > libgig API. But that's still in the works on my side.
That sounds really interesting! I could imagine using that directly,
when it's ready. Looking forward to that!
Cheers,
Kolja
Am Sonntag, dem 05.09.2021 um 18:48 +0200 schrieb Christian
Schoenebeck:
> On Sonntag, 5. September 2021 15:45:15 CEST Kolja Koch wrote:
> > Hi Christian,
> >
> > cool, thanks a lot for this!
> > As far as I understand it, I will be able to use that in my 'gig-
> > creator', that I'm working on (by the way, I ended up using
> > wxWidget).
>
> Yes, for now you would probably assemble a command line and call the
> system()
> function to execute the assembled command line, something like:
>
> int res = system("wav2gig --name1-regex '" + name1Pattern +
> ... );
>
> Later on I will make that available by more convenient functions via
> the
> libgig API. But that's still in the works on my side.
>
> I also slightly changed the default regex patterns, which are now
> like this:
>
> [^-\/\\]+ - [^-]+ - [^-]+ - [^-]+ - [^.]+
>
> Tearing that pattern down:
>
> [^-\/\\]+
>
> Which means "any sequence of characters except minus ('-'),
> forward slash
> ('/') or backslash ('\')". Basically this strips away a leading
> path like
> "/some/where/foo.wav" or "C:\some\where\foo.wav" and stops before
> the next
> " - " delimiter starts.
>
> [^-]+
>
> Any character sequence except minus ('-'). So it stops
> before the next
> " - " delimiter starts.
>
> [^.]+
>
> Any character sequence except dot ('.'). That strips away the
> trailing
> path extension, typically ".wav" or ".WAV".
>
> One more tip: if you are choosing C++ then I recommend to use C++11
> string
> literals for your regex code. That avoids having to double escape:
>
> // double escaped required (one for regex, one for C++)
> string pattern = "[^-\\/\\\\]+";
>
> vs.
>
> // single escape being sufficient (for regex only)
> string pattern = R"RegEx([^-\/\\]+)RegEx";
>
> That way you can also directly copy & paste the regex code from your
> source
> code into any RegEx debugging tool of your choice and vice versa.
>
> CU
> Christian
>
>
>
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
|
|
From: Christian S. <sch...@li...> - 2021-09-05 16:48:48
|
On Sonntag, 5. September 2021 15:45:15 CEST Kolja Koch wrote:
> Hi Christian,
>
> cool, thanks a lot for this!
> As far as I understand it, I will be able to use that in my 'gig-
> creator', that I'm working on (by the way, I ended up using wxWidget).
Yes, for now you would probably assemble a command line and call the system()
function to execute the assembled command line, something like:
int res = system("wav2gig --name1-regex '" + name1Pattern + ... );
Later on I will make that available by more convenient functions via the
libgig API. But that's still in the works on my side.
I also slightly changed the default regex patterns, which are now like this:
[^-\/\\]+ - [^-]+ - [^-]+ - [^-]+ - [^.]+
Tearing that pattern down:
[^-\/\\]+
Which means "any sequence of characters except minus ('-'), forward slash
('/') or backslash ('\')". Basically this strips away a leading path like
"/some/where/foo.wav" or "C:\some\where\foo.wav" and stops before the next
" - " delimiter starts.
[^-]+
Any character sequence except minus ('-'). So it stops before the next
" - " delimiter starts.
[^.]+
Any character sequence except dot ('.'). That strips away the trailing
path extension, typically ".wav" or ".WAV".
One more tip: if you are choosing C++ then I recommend to use C++11 string
literals for your regex code. That avoids having to double escape:
// double escaped required (one for regex, one for C++)
string pattern = "[^-\\/\\\\]+";
vs.
// single escape being sufficient (for regex only)
string pattern = R"RegEx([^-\/\\]+)RegEx";
That way you can also directly copy & paste the regex code from your source
code into any RegEx debugging tool of your choice and vice versa.
CU
Christian
|
|
From: Kolja K. <ko...@fr...> - 2021-09-05 13:45:02
|
Hi Christian, cool, thanks a lot for this! As far as I understand it, I will be able to use that in my 'gig- creator', that I'm working on (by the way, I ended up using wxWidget). I will post as soon as I have something usable. Cheers, Kolja > > Done. > > See latest revision of 'man wav2gig' how this tool behaves now: > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/man/wav2gig.1.in?view=markup > > CU > Christian > > > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Christian S. <sch...@li...> - 2021-09-03 15:11:42
|
On Sonntag, 29. August 2021 15:11:27 CEST Christian Schoenebeck wrote: > On Samstag, 28. August 2021 20:23:34 CEST Kolja Koch wrote: > > > wav2gig -a '(.*) - \d* - .* - .*.wav" \ > > > > > > -b '.* - (\d*) - .* - .*.wav" \ > > > -c '.* - \d* - (.*) - .*.wav" \ > > > -d '.* - \d* - .* - (.*).wav" > > > > It took me a moment to understand your proposal right. > > That is indeed very flexible, especially when combined with > > > > > pattern1|pattern2|pattern3 > > > > as you proposed. > > Also, this would make wav2gig easily to be invoked by other programs. > > > > From a user point of view, this anyway seems to me like it's hard to > > understand. E.g. if I'm no programmer and would be confronted with this > > kind of logic, I'd be scared away very soon. > > > > So why not use both approaches? > > - implement those name-switches as of your example > > - write a wrapper for wav2gig with a commandline-interface using the > > easytag-logic or whatever we would agree to be user-friendly. Not all > > name-schemes would have to be implemented here. This will call wav2gig > > with the corresponding Name-switches. > > - Write a real gui for that wrapper, that might be invoked by e.g. > > gigedit. [...] > Regex patterns are doing the job, including use cases that go beyond your > personal needs, and I don't have to maintain parsing code by myself. So the > plan is to make this feature configurable by standard regex patterns only > for now; no self-invented formats/tags and no custom parser code on top > that would need to be developed, documented, extended and ... fixed. > Instead some regex examples in the man page should already be a good > starting point for new users. > > For more complex uses cases there are plenty of RegEx howtos and live RegEx > debug tools on the net. And if someone fails: there is still this mailing > list and the forum site where users can just ask. > > Additionally I would add a verbosity switch and maybe a --dry-run switch for > providing users diagnostics for the individual input wav files' meta info > being picked by wav2gig and why. But that should be really it for > foreseeable future. Done. See latest revision of 'man wav2gig' how this tool behaves now: http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/man/wav2gig.1.in?view=markup CU Christian |
|
From: Christian S. <sch...@li...> - 2021-08-29 14:49:23
|
On Sonntag, 29. August 2021 15:41:06 CEST Kolja Koch wrote: > > Regex patterns are doing the job, including use cases that go beyond > > your > > personal needs, and I don't have to maintain parsing code by myself. > > So the > > plan is to make this feature configurable by standard regex patterns > > only for > > now; no self-invented formats/tags and no custom parser code on top > > that would > > need to be developed, documented, extended and ... fixed. Instead > > some regex > > examples in the man page should already be a good starting point for > > new > > users. > > As I said, that's fine with me. This could lead to a commandline > switch, where for each attribute a regex would be given. That should be > a relatively small patch. Exactly. Small changes, little worries. > > People who might refrain from using the wav2gig tool because of regex > > patterns > > being user-unfriendly, usually neither want to use command line tools > > in the > > first place. So for such people you would rather want to write a GUI > > app ontop > > of libgig where you could really invest a *load* of development time > > and > > people would probably still give you suggestions how it could be > > improved. > > E.g. you can make a clickable pattern editor with coloured > > highlighting and > > nice token frames that would show you a preview of the expected > > results in > > real-time, and you could combine that with an automatic prescan of a > > directory > > and deploy an A.I. on top of the prescan for a fully automated > > initial pattern > > suggestion. > : > :) Yes, I thought about these suggestions as well, including the A.I.. Yeah, I know. :) > : > > Well, if you really want to start such kind of project: I would > > recommend to > > reconsider the toolkit decision and no longer use gtk(mm) for new > > projects > > anymore, for many reasons actually. You would probably safe yourself > > a load of > > development time and frustration on the long run by simply picking > > another > > toolkit right from the start. > > Do you have any suggestions for one? I better don't. ;-) If you asked me couple years ago, I would have clearly said Qt. Nowadays the latter also aged and lacks things that I would expect from a modern UI toolkit today. > I just picked gtk because gigedit uses it... gigedit still uses gtk(mm) simply because it was started that way, and it probably always will, because a rewrite for another toolkit would be too much work now. AFAICR when Andreas started work on gigedit he expected of spending just like few weeks of spare-time on it, so AFAIK he picked a toolkit that matched natively/visually his personal favourite desktop at that time. CU Christian |
|
From: Kolja K. <ko...@fr...> - 2021-08-29 13:40:59
|
> Because somebody would need to write *and* maintain all of that > software. Keep > in mind that almost all people stepping by here are usually just > saying > feature x doesn't work, please fix it. Or feature y is nice, but > please extend > it in this and that way. > True! > I understand that you would like to see those wav2gig patterns more > user > friendly, but wav2gig is just one of many things (and projects) I > have to take > care of and I only have two hands and 24h/day. wav2gig is out for > just 2 weeks > now and you are probably one of the first people ever having used it > at all > (yet). So that's the infamous point where I have to make clear > compromises ... I'm absolutely with you! > > Regex patterns are doing the job, including use cases that go beyond > your > personal needs, and I don't have to maintain parsing code by myself. > So the > plan is to make this feature configurable by standard regex patterns > only for > now; no self-invented formats/tags and no custom parser code on top > that would > need to be developed, documented, extended and ... fixed. Instead > some regex > examples in the man page should already be a good starting point for > new > users. As I said, that's fine with me. This could lead to a commandline switch, where for each attribute a regex would be given. That should be a relatively small patch. > > Additionally I would add a verbosity switch and maybe a --dry-run > switch for > providing users diagnostics for the individual input wav files' meta > info > being picked by wav2gig and why. But that should be really it for > foreseeable > future. Ok! > > On Sonntag, 29. August 2021 12:30:13 CEST Kolja Koch wrote: > > Having wav2gig to accept regex-patterns for each attribute is fine > > with > > me. But from a user point of view, having an interface that allows > > him > > to easily enter patterns for the attributes for (some kind of > > simple) > > filename-structures would be recommendable. > > Yes, but you can also easily over-engineer this as well. ATM I don't > see this > conversion tool being used by a huge amount of people, nor on a > frequent > basis. Hence I personally don't want to invest too much time and > focus on it, > at least not ATM. Yeah, I have the same feeling. > > People who might refrain from using the wav2gig tool because of regex > patterns > being user-unfriendly, usually neither want to use command line tools > in the > first place. So for such people you would rather want to write a GUI > app ontop > of libgig where you could really invest a *load* of development time > and > people would probably still give you suggestions how it could be > improved. > E.g. you can make a clickable pattern editor with coloured > highlighting and > nice token frames that would show you a preview of the expected > results in > real-time, and you could combine that with an automatic prescan of a > directory > and deploy an A.I. on top of the prescan for a fully automated > initial pattern > suggestion. :) Yes, I thought about these suggestions as well, including the A.I.. > > Well, if you really want to start such kind of project: I would > recommend to > reconsider the toolkit decision and no longer use gtk(mm) for new > projects > anymore, for many reasons actually. You would probably safe yourself > a load of > development time and frustration on the long run by simply picking > another > toolkit right from the start. Do you have any suggestions for one? I just picked gtk because gigedit uses it... I really appreciate your taking the time for this conversation! And I really don't want this to consume more of your time. To me, this would be just a hobby-project to see if I can make that work. I can live with implementing and using the patch noted above just for my local project. If I succeed and get something together that I feel to be ready enough to be shared, I'll let you know. Cheers, Kolja |
|
From: Christian S. <sch...@li...> - 2021-08-29 13:11:40
|
On Samstag, 28. August 2021 20:23:34 CEST Kolja Koch wrote:
> > wav2gig -a '(.*) - \d* - .* - .*.wav" \
> > -b '.* - (\d*) - .* - .*.wav" \
> > -c '.* - \d* - (.*) - .*.wav" \
> > -d '.* - \d* - .* - (.*).wav"
>
> It took me a moment to understand your proposal right.
> That is indeed very flexible, especially when combined with
>
> > pattern1|pattern2|pattern3
>
> as you proposed.
> Also, this would make wav2gig easily to be invoked by other programs.
>
> From a user point of view, this anyway seems to me like it's hard to
> understand. E.g. if I'm no programmer and would be confronted with this
> kind of logic, I'd be scared away very soon.
>
> So why not use both approaches?
> - implement those name-switches as of your example
> - write a wrapper for wav2gig with a commandline-interface using the
> easytag-logic or whatever we would agree to be user-friendly. Not all
> name-schemes would have to be implemented here. This will call wav2gig
> with the corresponding Name-switches.
> - Write a real gui for that wrapper, that might be invoked by e.g.
> gigedit.
Because somebody would need to write *and* maintain all of that software. Keep
in mind that almost all people stepping by here are usually just saying
feature x doesn't work, please fix it. Or feature y is nice, but please extend
it in this and that way.
I understand that you would like to see those wav2gig patterns more user
friendly, but wav2gig is just one of many things (and projects) I have to take
care of and I only have two hands and 24h/day. wav2gig is out for just 2 weeks
now and you are probably one of the first people ever having used it at all
(yet). So that's the infamous point where I have to make clear compromises ...
Regex patterns are doing the job, including use cases that go beyond your
personal needs, and I don't have to maintain parsing code by myself. So the
plan is to make this feature configurable by standard regex patterns only for
now; no self-invented formats/tags and no custom parser code on top that would
need to be developed, documented, extended and ... fixed. Instead some regex
examples in the man page should already be a good starting point for new
users.
For more complex uses cases there are plenty of RegEx howtos and live RegEx
debug tools on the net. And if someone fails: there is still this mailing list
and the forum site where users can just ask.
Additionally I would add a verbosity switch and maybe a --dry-run switch for
providing users diagnostics for the individual input wav files' meta info
being picked by wav2gig and why. But that should be really it for foreseeable
future.
On Sonntag, 29. August 2021 12:30:13 CEST Kolja Koch wrote:
> Having wav2gig to accept regex-patterns for each attribute is fine with
> me. But from a user point of view, having an interface that allows him
> to easily enter patterns for the attributes for (some kind of simple)
> filename-structures would be recommendable.
Yes, but you can also easily over-engineer this as well. ATM I don't see this
conversion tool being used by a huge amount of people, nor on a frequent
basis. Hence I personally don't want to invest too much time and focus on it,
at least not ATM.
People who might refrain from using the wav2gig tool because of regex patterns
being user-unfriendly, usually neither want to use command line tools in the
first place. So for such people you would rather want to write a GUI app ontop
of libgig where you could really invest a *load* of development time and
people would probably still give you suggestions how it could be improved.
E.g. you can make a clickable pattern editor with coloured highlighting and
nice token frames that would show you a preview of the expected results in
real-time, and you could combine that with an automatic prescan of a directory
and deploy an A.I. on top of the prescan for a fully automated initial pattern
suggestion.
The more you think about it, the more desirable extensions you will find.
However the question always is: who will develop and maintain all of this.
> This is where (my beloved;) specifiers might do the trick. Beside the
> fact that they allow specifying all attributes in a one liner, checks
> against required attribute-formats would be implemented.
> The interface's output would be a command invoking wav2gig with the
> corresponding regex-patterns per attribute.
> This shouldn't be too difficult to implement, basically it's just a
> replacement of e.g.
> NoteNr %3r with (\d{3})
> or
> NoteName %a with ([c|d|e|f|g|a|b|c]+)(.*)(-?)(\d+)
>
> If you really want to allow to have alternative patterns for the same
> attribute, this could be implemented as well, e.g. using #[number]
> like:
> /path/%#2r/filename%#1r.wav
>
> which would result in the following regex-pattern for NoteNr:
>
> /path/.*/filename(\d+)\.wav|(/path/(\d+)/filename.*\.wav
>
> where '%#2r' is replaced by '.*' in the first alternative.
>
> I could imagine writing this with gtkmm (glade), but have no experience
> with that (only did some ncurses before), so I don't know how long that
> would take.
Well, if you really want to start such kind of project: I would recommend to
reconsider the toolkit decision and no longer use gtk(mm) for new projects
anymore, for many reasons actually. You would probably safe yourself a load of
development time and frustration on the long run by simply picking another
toolkit right from the start.
CU
Christian
|
|
From: Kolja K. <ko...@fr...> - 2021-08-29 10:30:24
|
I was thinking a little bit more about this.
Maybe we should agree upon some kind of complexity-level we want to
catch.
For instance:
The user might want to put samples into a gig-file, that have no common
filename structure. We could write an interface to let him enter the
required attributes (with regex or what ever) for each filename and
give wav2gig an array containing those attributes per filename.
But I believe, this is not somehting we would want to capture, since
the user could instead use gigedit directly to create that gig-file.
So the question is where tu pull the line between filename-complexity
and usability.
Having wav2gig to accept regex-patterns for each attribute is fine with
me. But from a user point of view, having an interface that allows him
to easily enter patterns for the attributes for (some kind of simple)
filename-structures would be recommendable.
This is where (my beloved;) specifiers might do the trick. Beside the
fact that they allow specifying all attributes in a one liner, checks
against required attribute-formats would be implemented.
The interface's output would be a command invoking wav2gig with the
corresponding regex-patterns per attribute.
This shouldn't be too difficult to implement, basically it's just a
replacement of e.g.
NoteNr %3r with (\d{3})
or
NoteName %a with ([c|d|e|f|g|a|b|c]+)(.*)(-?)(\d+)
If you really want to allow to have alternative patterns for the same
attribute, this could be implemented as well, e.g. using #[number]
like:
/path/%#2r/filename%#1r.wav
which would result in the following regex-pattern for NoteNr:
/path/.*/filename(\d+)\.wav|(/path/(\d+)/filename.*\.wav
where '%#2r' is replaced by '.*' in the first alternative.
I could imagine writing this with gtkmm (glade), but have no experience
with that (only did some ncurses before), so I don't know how long that
would take.
Have a nice sunday!
Kolja
They could also be embedded in a regex-logic.
Am Samstag, dem 28.08.2021 um 20:23 +0200 schrieb Kolja Koch:
>
> >
> I think it's because I'm a little more used to it...
> > more
> > simple on first view. But keep in mind both on your easy tag
> > example
> > and
> > printf the actual purpose deals with the other way around: e.g. in
> > the easy
> > tag example the individual components where already gathered
> > (extracted from
> > the MP3 files), and the actual intention was to assemble one string
> > from those
> > individual components, which is really just a string concatenation
> > operation.
> >
> It also works the other way around, it indeed allows you to get the
> tags out of the filenames and/or paths to fill the ID-tags, if those
> are missing.
> See attached screenshot.
>
>
> >
> > wav2gig -a '(.*) - \d* - .* - .*.wav" \
> > -b '.* - (\d*) - .* - .*.wav" \
> > -c '.* - \d* - (.*) - .*.wav" \
> > -d '.* - \d* - .* - (.*).wav"
> >
> >
> It took me a moment to understand your proposal right.
> That is indeed very flexible, especially when combined with
> > pattern1|pattern2|pattern3
> as you proposed.
> Also, this would make wav2gig easily to be invoked by other programs.
>
> From a user point of view, this anyway seems to me like it's hard to
> understand. E.g. if I'm no programmer and would be confronted with
> this
> kind of logic, I'd be scared away very soon.
>
> So why not use both approaches?
> - implement those name-switches as of your example
> - write a wrapper for wav2gig with a commandline-interface using the
> easytag-logic or whatever we would agree to be user-friendly. Not all
> name-schemes would have to be implemented here. This will call
> wav2gig
> with the corresponding Name-switches.
> - Write a real gui for that wrapper, that might be invoked by e.g.
> gigedit.
>
> Cheers,
> Kolja
>
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
|
|
From: Kolja K. <ko...@fr...> - 2021-08-28 18:23:26
|
> > I understand that you like the printf specifier format, as it looks I think it's because I'm a little more used to it... > more > simple on first view. But keep in mind both on your easy tag example > and > printf the actual purpose deals with the other way around: e.g. in > the easy > tag example the individual components where already gathered > (extracted from > the MP3 files), and the actual intention was to assemble one string > from those > individual components, which is really just a string concatenation > operation. > It also works the other way around, it indeed allows you to get the tags out of the filenames and/or paths to fill the ID-tags, if those are missing. See attached screenshot. > > wav2gig -a '(.*) - \d* - .* - .*.wav" \ > -b '.* - (\d*) - .* - .*.wav" \ > -c '.* - \d* - (.*) - .*.wav" \ > -d '.* - \d* - .* - (.*).wav" > > It took me a moment to understand your proposal right. That is indeed very flexible, especially when combined with > pattern1|pattern2|pattern3 as you proposed. Also, this would make wav2gig easily to be invoked by other programs. >From a user point of view, this anyway seems to me like it's hard to understand. E.g. if I'm no programmer and would be confronted with this kind of logic, I'd be scared away very soon. So why not use both approaches? - implement those name-switches as of your example - write a wrapper for wav2gig with a commandline-interface using the easytag-logic or whatever we would agree to be user-friendly. Not all name-schemes would have to be implemented here. This will call wav2gig with the corresponding Name-switches. - Write a real gui for that wrapper, that might be invoked by e.g. gigedit. Cheers, Kolja |
|
From: Christian S. <sch...@li...> - 2021-08-28 17:14:34
|
On Samstag, 28. August 2021 18:29:21 CEST Kolja Koch wrote:
> > Could you please elaborate, i.e. examples of where you would see
> >
> > > issues by
> > > just supplying regex patterns from the command line?
>
> Sure!
>
> I don't know in which order the attributes might be.
> The regex you implemented uses a fixed order:
>
> '(Name1)(Name2)(Velocity)(Note_Nr)(Note_Name)'
>
> Take the following filename:
>
> 'Name - 64 - Bb3 - articulation.wav'
>
> A regex-pattern could look like this:
>
> '(.*) - (\d*) - (.*) - (.*).wav'
>
> But how would the code know, that '64' is meant to be the velocity?
> Or that 'Bb3' is a NoteName and 'articulation' is Name2?
>
> One would also somehow have to enter the correct order, like
>
> '(Name1)(Velocity)(Note_Name)(Name2)',
>
> or am I missing something?
Yes, but that's not how I would have exposed it to the command line interface
anyway. See below of what I had in mind ...
> By using format specifiers, like in printf, you would simply enter:
>
> '%n - %v - %a - %m.wav'
> (where %n = Name1, %v = velocity, %a = Note_Name, %m = Name2)
I understand that you like the printf specifier format, as it looks more
simple on first view. But keep in mind both on your easy tag example and
printf the actual purpose deals with the other way around: e.g. in the easy
tag example the individual components where already gathered (extracted from
the MP3 files), and the actual intention was to assemble one string from those
individual components, which is really just a string concatenation operation.
In case of wav2gig however we need the other way around, i.e. you have one
string (file name incl. path) and you need to extract the individual
components from that string. Which is a much more delicate task due to the
large freedom such kind of input strings can have.
So your proposal would be something like this:
wav2gig --pattern '%a - %b - %c - %d.wav'
you would not be buying much with that compared to e.g.:
wav2gig -a '(.*) - \d* - .* - .*.wav" \
-b '.* - (\d*) - .* - .*.wav" \
-c '.* - \d* - (.*) - .*.wav" \
-d '.* - \d* - .* - (.*).wav"
which still could be simplified by the user (the patterns I mean), so that's
not my point here. The main issue with your solution is that you very easily
run into limitations of what it could do.
For instance say for some wav files you want the note number to be extracted
from a path, and only if that path is not available then extract it from the
file name. There is nothing to be invented on our side; regex already supports
this e.g. by using the alternate operator:
pattern1|pattern2|pattern3
where priority is from left to right.
Or you wanted something inside the string to be optional. Likewise, the user
would just prepend a question mark. All these things are standardized, well
documented, and nothing we have to take care about ourselves.
CU
Christian
|
|
From: Kolja K. <ko...@fr...> - 2021-08-28 16:29:16
|
> Could you please elaborate, i.e. examples of where you would see
> > issues by
> > just supplying regex patterns from the command line?
Sure!
I don't know in which order the attributes might be.
The regex you implemented uses a fixed order:
'(Name1)(Name2)(Velocity)(Note_Nr)(Note_Name)'
Take the following filename:
'Name - 64 - Bb3 - articulation.wav'
A regex-pattern could look like this:
'(.*) - (\d*) - (.*) - (.*).wav'
But how would the code know, that '64' is meant to be the velocity?
Or that 'Bb3' is a NoteName and 'articulation' is Name2?
One would also somehow have to enter the correct order, like
'(Name1)(Velocity)(Note_Name)(Name2)',
or am I missing something?
By using format specifiers, like in printf, you would simply enter:
'%n - %v - %a - %m.wav'
(where %n = Name1, %v = velocity, %a = Note_Name, %m = Name2)
I implemented some more checks today, each attribute is now checked
against a given regex-string, e.g. NoteName:
(^[c|C|d|D|e|E|f|F|g|G|a|A|b|B].*-?\\d+$)
where a pattern for the signs ('.*' in the string) will have to be
supplied if no Note_Nr is available in the filename (defaults to '#'
and 'b').
Also, it is checked that all required values for further processing are
available (for now: Name1, Velocity, Note_Nr).
It 'should' be quite robust now, I believe.
Both updated files are attached (patch created against wav2gig.cpp from
today).
Of course, all the information and examples at the beginning could go
into the manpage, but I would recommend to at least print the available
specifiers (if you want to use the filenamescanner at all...;).
> The patch also adds
> > > "
> > > } else {
> > > s->MIDIUnityNote = wav->note;
> > > "
> > > as you proposed.
> >
> > I committed that now, because no matter how the naming scheme
> > evolves, this
> > change makes sense anyway.
Cool, thanks!
Cheers,
Kolja
|
|
From: Christian S. <sch...@li...> - 2021-08-28 13:51:39
|
On Freitag, 27. August 2021 21:19:27 CEST Kolja Koch wrote:
> Hi Christian,
>
> thanks a lot for the info!
>
> Regarding regex:
> I know regex, but was not too familiar with it.
> From what I understand, it is hard to foresee, in what order the
> attributes are in the filename, which makes direct usage of regex
> difficult.
Could you please elaborate, i.e. examples of where you would see issues by
just supplying regex patterns from the command line?
> The patch also adds
> "
> } else {
> s->MIDIUnityNote = wav->note;
> "
> as you proposed.
I committed that now, because no matter how the naming scheme evolves, this
change makes sense anyway.
CU
Christian
|
|
From: Kolja K. <ko...@fr...> - 2021-08-27 19:19:29
|
Hi Christian,
thanks a lot for the info!
Regarding regex:
I know regex, but was not too familiar with it.
>From what I understand, it is hard to foresee, in what order the
attributes are in the filename, which makes direct usage of regex
difficult.
I already toyed around a little bit and wrote a patch (2 files
attached), that will do the following:
- Use '-s' as a switch to use the 'filenamescanner'.
- You will be presented with some instructions on how to use it.
Basically, this works like formatting with printf. Also, the first
filename of the set will be printed.
- Enter a 'scheme' that will be used to parse the filenames.
- Eventually enter required attributes that are missing in the filename
(like e.g. velocity, that would be a constant for all samples then).
- Show the result based on the first filename in the set.
- Proceed, retry or abort.
It uses regex to parse the input-scheme and thereby create another
regex-string (that will then parse the filenames) plus mapping of the
found patterns to the corresponding attributes.
The code calculates NOTE_NRs out of NOTE_NAMES and vice versa, if
either one is missing.
The patch also adds
"
} else {
s->MIDIUnityNote = wav->note;
"
as you proposed.
To be done:
- code-cleanup
- test and implement checks against sane input (e.g. NOTE_NR has a
valid format) and make code more robust.
- 'hide' filename-path, only the filename itself is relevant.
(Although, expanding the usage of wav2gig to be able to create multiple
gig-files based on a directory-structure could be interesting.)
Wonnahave:
- A flag for automatically generating the .gig-filename like e.g.
'NAME1 - NAME2.gig'.
- The possibility, to automatically join two mono-wav-files into one
stereo-wav-file. Another specifier for identifying those in the
filename could be added, like %s. Currently, this has to be done
'manually' (e.g. with sox), bevor using wav2gig.
- a flag to expanse the created regions (with a minimum of pitch-
correction), so that a gapless, ready-to-use instrument is created.
I think, this would make the tool very valuable for creating
instruments from scratch.
As I said, this is my first contribution (and the first patch I ever
wrote), I still lack knowledge of versioning and writing code that is
e.g. windows-compatible (I'm on Archlinux, had to adjust the PKGBUILD
of libgig-svn since it woldn't compile due to pango-errors), so bare
with me... ;)
If you'd rather go into another direction, that is fine with me as
well, it still was a good exercise for me :)
Let me know what you think!
Cheers,
Kolja
P.S.: I put the functions for the filenamescanner into a separate file
(filenamescanner.cpp). Both files need to be in the directory of
wav2gig.cpp since I don't know how this is usually done.
Am Donnerstag, dem 26.08.2021 um 15:35 +0200 schrieb Christian
Schoenebeck:
> On Mittwoch, 25. August 2021 12:26:38 CEST Kolja Koch wrote:
> > Hello all,
> >
> > I played around a little bit with the wav2gig tool, in order to get
> > samples extracted by akaiextract into a gig-file.
> > Currently, wav2gig only supports a hard coded naming convention for
> > the
> > wav-files in order to get the information needed for the import
> > process.
> >
> > - Are there any plans to integrate the import-process into gigedit?
>
> In libgig there is already a quite a collection of individual command
> line
> tools. The plan is to first make these already existing tools available
> through a convenient API accessible from the libgig DLL itself. I've
> already
> started work on this on libgig side (not committed yet).
>
> As a next step GUI applications like GigEdit would be extended to call
> those
> libgig functions to offer the respective tools like conversions,
> integrity
> checks, and so forth. This could obviously then also be used by other
> GUI
> apps.
>
> > If so, we could present the user with an interface similar to the
> > "Fill
> > Tag" scanner in eastag:
> > http://src.gnu-darwin.org/ports/audio/easytag/work/easytag-2.1/doc/EasyTAG_D
> > ocumentation.html#vh_1_2_2 Note: Any characters in the filename that
> > should
> > be ignored can be entered directly and work like a delimiter, just
> > like the
> > " - " in the example.
>
> wav2gig.cpp already uses regular expressions (RegEx) to extract info
> from the
> individual file names. These RegEx patterns are currently hard coded in
> wav2gig.cpp, but the plan was to use them just as default RegEx
> patterns and
> allowing to override them individually with custom RegEx patterns from
> the
> command line if needed.
>
> While the template format in EasyTag is easier to understand, it is
> also much
> more limited than RegEx patterns.
>
> Regular expressions are a common standard for text parsing tasks across
> all
> programming languages, including shell scripts.
>
> > Disadvantage is, that this will only work, if there are indeed
> > delimiters. In my case, the filenames look like this:
> > 'STFLSF 5 L.wav'
> > where
> > 'ST' is the instrument,
> > 'FLS' the articulation and
> > 'F 5' is the note 'F#5'.
> > The 'L' stands for 'left', as there is also a file for the right
> > channel.
> >
> > Unfortunately, there is also
> > 'STFLSF5 L.wav'
> > where 'F5' is the note 'F5'.
> > Theoretically, there could also be a 'F -1' (= 'F#-1').
> >
> > I know, we cannot cover any name-scheme one might (not) think of, but
> > as you can see, the only 'dynamic' part of the filename in my case is
> > the note-name, so using the 'easytag'-scanner I could enter
> > 'STFLS%n '
> > where %n would refer to the note-name.
>
> Yeah, but RegEx patterns can handle all of them, and also much more
> complicated file name scenarios beyond that.
>
> I highly recommend you to readup on RegEx patterns, as this is a highly
> valueable knowledge for any programmer, even if you are just writing
> shell
> scripts. There are also plenty of sites online that allow you to toy
> arround
> live with RegEx patterns and arbitrary input, with coloured visual
> diagnostics
> how the example input text was exactly tokenized, syntax help and much
> more.
>
> [...]
> > I'm willing to participate on this, though my programming-skills are
> > those of a layman... ;)
>
> Well, in this particular case, all you need is inside wav2gig.cpp,
> which is a
> understand and adjust this code, even for beginners.
>
> CU
> Christian
>
>
>
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
|
|
From: Christian S. <sch...@li...> - 2021-08-26 14:07:45
|
On Mittwoch, 25. August 2021 12:26:38 CEST Kolja Koch wrote: > Hello all, > > I played around a little bit with the wav2gig tool, in order to get > samples extracted by akaiextract into a gig-file. > Currently, wav2gig only supports a hard coded naming convention for the > wav-files in order to get the information needed for the import > process. > > - Are there any plans to integrate the import-process into gigedit? In libgig there is already a quite a collection of individual command line tools. The plan is to first make these already existing tools available through a convenient API accessible from the libgig DLL itself. I've already started work on this on libgig side (not committed yet). As a next step GUI applications like GigEdit would be extended to call those libgig functions to offer the respective tools like conversions, integrity checks, and so forth. This could obviously then also be used by other GUI apps. > If so, we could present the user with an interface similar to the "Fill > Tag" scanner in eastag: > http://src.gnu-darwin.org/ports/audio/easytag/work/easytag-2.1/doc/EasyTAG_D > ocumentation.html#vh_1_2_2 Note: Any characters in the filename that should > be ignored can be entered directly and work like a delimiter, just like the > " - " in the example. wav2gig.cpp already uses regular expressions (RegEx) to extract info from the individual file names. These RegEx patterns are currently hard coded in wav2gig.cpp, but the plan was to use them just as default RegEx patterns and allowing to override them individually with custom RegEx patterns from the command line if needed. While the template format in EasyTag is easier to understand, it is also much more limited than RegEx patterns. Regular expressions are a common standard for text parsing tasks across all programming languages, including shell scripts. > Disadvantage is, that this will only work, if there are indeed > delimiters. In my case, the filenames look like this: > 'STFLSF 5 L.wav' > where > 'ST' is the instrument, > 'FLS' the articulation and > 'F 5' is the note 'F#5'. > The 'L' stands for 'left', as there is also a file for the right > channel. > > Unfortunately, there is also > 'STFLSF5 L.wav' > where 'F5' is the note 'F5'. > Theoretically, there could also be a 'F -1' (= 'F#-1'). > > I know, we cannot cover any name-scheme one might (not) think of, but > as you can see, the only 'dynamic' part of the filename in my case is > the note-name, so using the 'easytag'-scanner I could enter > 'STFLS%n ' > where %n would refer to the note-name. Yeah, but RegEx patterns can handle all of them, and also much more complicated file name scenarios beyond that. I highly recommend you to readup on RegEx patterns, as this is a highly valueable knowledge for any programmer, even if you are just writing shell scripts. There are also plenty of sites online that allow you to toy arround live with RegEx patterns and arbitrary input, with coloured visual diagnostics how the example input text was exactly tokenized, syntax help and much more. [...] > I'm willing to participate on this, though my programming-skills are > those of a layman... ;) Well, in this particular case, all you need is inside wav2gig.cpp, which is a quite simple and small source file. It should not be too difficult to understand and adjust this code, even for beginners. CU Christian |
|
From: Kolja K. <ko...@fr...> - 2021-08-25 10:44:56
|
Hello all, I played around a little bit with the wav2gig tool, in order to get samples extracted by akaiextract into a gig-file. Currently, wav2gig only supports a hard coded naming convention for the wav-files in order to get the information needed for the import process. - Are there any plans to integrate the import-process into gigedit? If so, we could present the user with an interface similar to the "Fill Tag" scanner in eastag: http://src.gnu-darwin.org/ports/audio/easytag/work/easytag-2.1/doc/EasyTAG_Documentation.html#vh_1_2_2 Note: Any characters in the filename that should be ignored can be entered directly and work like a delimiter, just like the " - " in the example. Disadvantage is, that this will only work, if there are indeed delimiters. In my case, the filenames look like this: 'STFLSF 5 L.wav' where 'ST' is the instrument, 'FLS' the articulation and 'F 5' is the note 'F#5'. The 'L' stands for 'left', as there is also a file for the right channel. Unfortunately, there is also 'STFLSF5 L.wav' where 'F5' is the note 'F5'. Theoretically, there could also be a 'F -1' (= 'F#-1'). I know, we cannot cover any name-scheme one might (not) think of, but as you can see, the only 'dynamic' part of the filename in my case is the note-name, so using the 'easytag'-scanner I could enter 'STFLS%n ' where %n would refer to the note-name. Missing paramters: - The notenumber could be extracted by investigating the notename - the sign-charater(s) should be entered (' ' in my case, might be '#', 'sharp', 'flat', 'is' or whatever). - 'name' (and name2) could be entered as a static value and eventually used for auto-generating the gig-filename. - velocity_nr could in my case also be entered as a static value (default = 64 or 127?) Exception to the given scheme that might occur during the import- process might have to be dealt with individually: ignore file (ignore all exceptions), abort import. Sidenote: With my filenames, it looks like they have a fixed length with each index with a fixed meaning. Another filename-scheme from my list: 'T1FTG2 AIF L.wav' index 0 to 1: name index 2 to 3: name2 index 4 to 6: note-name index 7 to 10: ??? index 11 : pan So this could lead to a different 'fixed-width' approach. Of course, this all could be implemented as commandline options to wav2gig, or maybe with a switch that will lead to an interactive 'shell': - Show the first found wav-filename - The user enters the name-scheme - The user enters missing information from the name-scheme as static values I'm willing to participate on this, though my programming-skills are those of a layman... ;) Cheers, Kolja |
|
From: Christian S. <sch...@li...> - 2021-05-14 09:22:00
|
On Donnerstag, 13. Mai 2021 22:20:26 CEST Barry Jackson wrote: > On 13/05/2021 18:23, Christian Schoenebeck wrote: > > Already filed: > > https://bugs.linuxsampler.org/cgi-bin/show_bug.cgi?id=193 > > > > I think some people are using a std lib call to generate a time stamp > > instead, which is not real-time safe though. A CPU/asm solution for > > generating the time stamp would be better. > > That bug is over 6 years old! > > So for now we just drop gig/linuxsampler/gigedit from all arm builds I > guess. Makes sense. > Is a solution being worked on? Not that I know of. The way to go is to read out the cpu cycle register, which is the fastest solution and real-time safe. The other asm code mentioned should already been taken care of. Best regards, Christian Schoenebeck |
|
From: Barry J. <zen...@ze...> - 2021-05-13 20:20:42
|
On 13/05/2021 18:23, Christian Schoenebeck wrote: > Already filed: > https://bugs.linuxsampler.org/cgi-bin/show_bug.cgi?id=193 > > I think some people are using a std lib call to generate a time stamp instead, > which is not real-time safe though. A CPU/asm solution for generating the time > stamp would be better. > That bug is over 6 years old! So for now we just drop gig/linuxsampler/gigedit from all arm builds I guess. Is a solution being worked on? Regards, Barry |
|
From: Christian S. <sch...@li...> - 2021-05-13 17:23:52
|
On Donnerstag, 13. Mai 2021 18:23:49 CEST Barry Jackson wrote: > Relevant lines from build log: > ------------------------------- > libtool: compile: g++ -std=gnu++14 -DHAVE_CONFIG_H -I. -I../.. > -Wreturn-type -ffast-math -O2 -g -pipe -Wformat -Werror=format-security > -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 > -fasynchronous-unwind-tables -pthread -c RTMath.cpp -fPIC -DPIC -o > .libs/RTMath.o > RTMath.cpp:83:8: error: #error "Sorry, LinuxSampler lacks time stamp > code for your system." > 83 | # error "Sorry, LinuxSampler lacks time stamp code for > your system." > > | ^~~~~ Already filed: https://bugs.linuxsampler.org/cgi-bin/show_bug.cgi?id=193 I think some people are using a std lib call to generate a time stamp instead, which is not real-time safe though. A CPU/asm solution for generating the time stamp would be better. Best regards, Christian Schoenebeck |
|
From: Barry J. <zen...@ze...> - 2021-05-13 16:37:00
|
On 13/05/2021 17:23, Barry Jackson wrote: > Not certain which build machine was used but one is Amazon Graviton 2 > and the others are older Graviton. It was the Graviton 2 on further investigation. |
|
From: Barry J. <zen...@ze...> - 2021-05-13 16:24:01
|
Relevant lines from build log:
-------------------------------
libtool: compile: g++ -std=gnu++14 -DHAVE_CONFIG_H -I. -I../..
-Wreturn-type -ffast-math -O2 -g -pipe -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
-fasynchronous-unwind-tables -pthread -c RTMath.cpp -fPIC -DPIC -o
.libs/RTMath.o
RTMath.cpp:83:8: error: #error "Sorry, LinuxSampler lacks time stamp
code for your system."
83 | # error "Sorry, LinuxSampler lacks time stamp code for
your system."
| ^~~~~
RTMath.cpp:84:8: error: #error "Please report this error and the CPU you
are using to the LinuxSampler developers mailing list!"
84 | # error "Please report this error and the CPU you are
using to the LinuxSampler developers mailing list!"
| ^~~~~
In file included from RTMath.h:29,
from RTMath.cpp:24:
global_private.h:99:40: warning: dynamic exception specifications are
deprecated in C++11 [-Wdeprecated]
99 | inline int ToInt(const std::string& s)
throw(LinuxSampler::Exception) {
| ^~~~~
global_private.h:106:44: warning: dynamic exception specifications are
deprecated in C++11 [-Wdeprecated]
106 | inline float ToFloat(const std::string& s)
throw(LinuxSampler::Exception) {
| ^~~~~
RTMath.cpp: In static member function 'static RTMathBase::time_stamp_t
RTMathBase::CreateTimeStamp()':
RTMath.cpp:86:1: warning: no return statement in function returning
non-void [-Wreturn-type]
86 | }
| ^
make[3]: *** [Makefile:558: RTMath.lo] Error 1
-----------------------------------------------
We have two patches applied:
linuxsampler-2.1-mga-arm_RTMath.cpp.patch
linuxsampler-2.1-mga-arm_atomic.h.patch
Not certain which build machine was used but one is Amazon Graviton 2
and the others are older Graviton.
Any help appreciated.
Thanks,
Barry Jackson
|
|
From: Rui N. C. <rn...@rn...> - 2021-05-11 17:49:09
|
Hi everybody, The first batch of the so called 'QStuff*' is springing out: QjackCtl [1], Qsynth [2], Qsampler [3], QXGEdit [4], QmidiCtl [5] and QmidiNet [6], all bumping to **version 0.9.3** for the (northern) Spring'21 season, rejoice! ** QjackCtl - JACK Audio Connection Kit Qt GUI Interface [1] ** QjackCtl 0.9.3 (spring'21) is released! QjackCtl is an aged yet modern, not so 'simple' anymore, Qt [7] application to control the JACK [8] sound server, for the Linux Audio [12] infrastructure. Website: https://qjackctl.sourceforge.io http://qjackctl.sourceforge.net Project page: https://sourceforge.net/projects/qjackctl Downloads: https://sourceforge.net/projects/qjackctl/files - source tarball: https://download.sf.net/qjackctl/qjackctl-0.9.3.tar.gz - source package: https://download.sf.net/qjackctl/qjackctl-0.9.3-47.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qjackctl/qjackctl-0.9.3-47.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qjackctl/qjackctl-0.9.3-47.x86_64.AppImage Git repos: https://git.code.sf.net/p/qjackctl/code https://github.com/rncbc/qjackctl.git https://gitlab.com/rncbc/qjackctl.git https://bitbucket.com/rncbc/qjackctl.git Change-log: - Graph connection lines drop-shadow eye-candy has been optimized, improving a lot on moving highly-connected nodes, especially the ones with plenty of backward-curved connections. - All packaging builds switching to CMake. [21] - Fixed default preset/aliases switching and reloading when entering pure-client mode (ie. "Active" status). ** Qsynth - A fluidsynth Qt GUI Interface [2] ** Qsynth 0.9.3 (spring'21) is released! Qsynth is a FluidSynth [10] GUI front-end application written in C++ around the Qt framework [7] using Qt Designer. Website: https://qsynth.sourceforge.io http://qsynth.sourceforge.net Project page: https://sourceforge.net/projects/qsynth Downloads: https://sourceforge.net/projects/qsynth/files - source tarball: https://download.sf.net/qsynth/qsynth-0.9.3.tar.gz - source package: https://download.sf.net/qsynth/qsynth-0.9.3-47.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qsynth/qsynth-0.9.3-47.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qsynth/qsynth-0.9.3-47.x86_64.AppImage - Win64 and macOS packages (thanks again to Pedro Lopez-Cabanillas): https://download.sf.net/qsynth/qsynth-0.9.3-47.win-x64-setup.exe https://download.sf.net/qsynth/qsynth-0.9.3-47.mac-x64.dmg Git repos: https://git.code.sf.net/p/qsynth/code https://github.com/rncbc/qsynth.git https://gitlab.com/rncbc/qsynth.git https://bitbucket.com/rncbc/qsynth.git Change-log: - New Setup/Audio/WASAPI Exclusive Mode option added. - Fix for Windows runtime error (assertion failed) when compiled with MSVC (by Pedro Lopez-Cabanillas). - New Setup/MIDI/Auto Connect MIDI inputs option added. - Fix deprecated Reverb/Chorus API (FluidSynth >= 2.2.0). - All packaging builds switching to CMake. [21] ** Qsampler - A LinuxSampler Qt GUI Interface [3] ** Qsampler 0.9.3 (spring'21) is released! Qsampler is a LinuxSampler [11] GUI front-end application written in C++ around the Qt framework [7] using Qt Designer. Website: https://qsampler.sourceforge.io http://qsampler.sourceforge.net Project page: https://sourceforge.net/projects/qsampler Downloads: https://sourceforge.net/projects/qsampler/files - source tarballs: https://download.sf.net/qsampler/qsampler-0.9.3.tar.gz https://download.sf.net/qsampler/liblscp-0.9.3.tar.gz - source packages: https://download.sf.net/qsampler/qsampler-0.9.3-47.rncbc.suse.src.rpm https://download.sf.net/qsampler/liblscp-0.9.3-47.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qsampler/qsampler-0.9.3-47.rncbc.suse.x86_64.rpm https://download.sf.net/qsampler/liblscp6-0.9.3-47.rncbc.suse.x86_64.rpm https://download.sf.net/qsampler/liblscp-devel-0.9.3-47.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qsampler/qsampler-0.9.3-47.x86_64.AppImage Git repos: https://git.code.sf.net/p/qsampler/code https://github.com/rncbc/qsampler.git https://gitlab.com/rncbc/qsampler.git https://bitbucket.com/rncbc/qsampler.git https://git.code.sf.net/p/qsampler/liblscp https://github.com/rncbc/liblscp.git https://gitlab.com/rncbc/liblscp.git https://bitbucket.com/rncbc/liblscp.git Change-log: - All packaging builds switching to CMake. [21] ** QXGEdit - A Qt XG Editor [4] ** QXGEdit 0.9.3 (spring'21) is released! QXGEdit is a live XG instrument editor, specialized on editing MIDI System Exclusive files (.syx) for the Yamaha DB50XG [14] and thus probably a baseline for many other XG devices. Website: https://qxgedit.sourceforge.io http://qxgedit.sourceforge.net Project page: https://sourceforge.net/projects/qxgedit Downloads: https://sourceforge.net/projects/qxgedit/files - source tarball: https://download.sf.net/qxgedit/qxgedit-0.9.3.tar.gz - source package: https://download.sf.net/qxgedit/qxgedit-0.9.3-37.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qxgedit/qxgedit-0.9.3-37.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qxgedit/qxgedit-0.9.3-37.x86_64.AppImage Git repos: https://git.code.sf.net/p/qxgedit/code https://github.com/rncbc/qxgedit.git https://gitlab.com/rncbc/qxgedit.git https://bitbucket.com/rncbc/qxgedit.git Change-log: - All packaging builds switching to CMake. [21] ** QmidiCtl - A MIDI Remote Controller via UDP/IP Multicast [5] ** QmidiCtl 0.9.3 (spring'21) is released! QmidiCtl [5] is a MIDI remote controller application that sends MIDI data over the network, using UDP/IP multicast. Inspired by multimidicast [15] and designed to be compatible with ipMIDI [15] for Windows. QmidiCtl [5] was long ago designed for the Maemo [17] enabled handheld devices, namely the late Nokia N900 [18] and promoted to the Maemo Package [18] repositories. Nevertheless, QmidiCtl [5] may still be found effective as a regular desktop application and recently as an Android application as well. Website: https://qmidictl.sourceforge.io http://qmidictl.sourceforge.net Project page: https://sourceforge.net/projects/qmidictl Downloads: https://sourceforge.net/projects/qmidictl/files - source tarball: https://download.sf.net/qmidictl/qmidictl-0.9.3.tar.gz - source package: https://download.sf.net/qmidictl/qmidictl-0.9.3-27.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qmidictl/qmidictl-0.9.3-27.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qmidictl/qmidictl-0.9.3-27.x86_64.AppImage - Android package: https://download.sf.net/qmidictl/qmidictl-0.9.3-27.aab https://play.google.com/store/apps/details?id=org.rncbc.qmidictl Git repos: https://git.code.sf.net/p/qmidictl/code https://github.com/rncbc/qmidictl.git https://gitlab.com/rncbc/qmidictl.git https://bitbucket.com/rncbc/qmidictl.git Change-log: - All packaging builds switching to CMake. [21] ** QmidiNet - A MIDI Network Gateway via UDP/IP Multicast [6] ** QmidiNet 0.9.3 (spring'21) is released! QmidiNet is a MIDI network gateway application that sends and receives MIDI data (ALSA-MIDI [9] and JACK-MIDI [8]) over the network, using UDP/IP multicast. Inspired by multimidicast [15] and designed to be compatible with ipMIDI [16] for Windows. Website: https://qmidinet.sourceforge.io http://qmidinet.sourceforge.net Project page: https://sourceforge.net/projects/qmidinet Downloads: https://sourceforge.net/projects/qmidinet/files - source tarball: https://download.sf.net/qmidinet/qmidinet-0.9.3.tar.gz - source package: https://download.sf.net/qmidinet/qmidinet-0.9.3-27.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qmidinet/qmidinet-0.9.3-27.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qmidinet/qmidinet-0.9.3-27.x86_64.AppImage Git repos: https://git.code.sf.net/p/qmidinet/code https://github.com/rncbc/qmidinet.git https://gitlab.com/rncbc/qmidinet.git https://bitbucket.com/rncbc/qmidinet.git Change-log: - All packaging builds switching to CMake. [21] License: All of the Qstuff* are free, open-source Linux Audio [11] software, distributed under the terms of the GNU General Public License (GPL) version 2 or later [12]. References: [1] QjackCtl - A JACK Audio Connection Kit Qt GUI Interface https://qjackctl.sourceforge.io [2] Qsynth - A fluidsynth Qt GUI Interface https://qsynth.sourceforge.io [3] Qsampler - A LinuxSampler Qt GUI Interface https://qsampler.sourceforge.io [4] QXGEdit - A Qt XG Editor https://qxgedit.sourceforge.io [5] QmidiCtl - A MIDI Remote Controller via UDP/IP Multicast https://qmidictl.sourceforge.io [6] QmidiNet - A MIDI Network Gateway via UDP/IP Multicast https://qmidinet.sourceforge.io [7] Qt framework, C++ class library and tools for cross-platform application and UI development https://qt.io/ [8] JACK Audio Connection Kit https://jackaudio.org [9] ALSA, Advanced Linux Sound Architecture https://www.alsa-project.org/ [10] FluidSynth - A SoundFont Synthesizer A real-time software synthesizer based on SoundFont 2 specifications https://www.fluidsynth.org [11] LinuxSampler - The Linux Sampler Project A modular, streaming capable, realtime audio sampler https://www.linuxsampler.org [12] Linux Audio consortium of libre software for audio-related work https://linuxaudio.org [13] GPL - GNU General Public License https://www.gnu.org/copyleft/gpl.html [14] Yamaha DB50XG (https://web.archive.org/web/20150607065739/) http://www.soundonsound.com/sos/1996_articles/may96/yamahadb50xg.html [15] multimidicast - sends and receives MIDI from ALSA sequencers over network https://llg.cubic.org/tools/multimidicast [16] ipMIDI - MIDI over Ethernet ports - send MIDI over your LAN https://nerds.de [17] Maemo.org - Home of the Maemo community https://www.maemo.org [18] Maemo.org Wiki - Nokia N900 https://wiki.maemo.org/Nokia_N900 [19] Maemo.org - Downloads: QmidiCtl https://maemo.org/downloads/product/Maemo5/qmidictl [20] AppImage, Linux apps that run anywhere https://appimage.org/ [21] CMake, a cross-platform, open-source build system generator https://cmake.org See also: https://www.rncbc.org/drupal/node/2224 Keep having fun && stay healthy, always! -- rncbc aka Rui Nuno Capela |
161 messages has been excluded from this view by a project administrator.
