Menu
▾
▴
zynaddsubfx-user
|
From: Abrolag <ab...@us...> - 2009-09-27 20:41:06
|
I thought I'd take a look at the experimental branch but can't seem to make head nor tail of sourceforge and git :( What command to I need to use to get this. -- Will J Godfrey http://www.musically.me.uk |
|
From: Harald H. <har...@gm...> - 2009-09-27 20:59:12
|
Sorry about the mess - the project page is supposed to list the command for that, but due to recent changes in sourceforge's git hosting the command listed there is not working. It should be updated now, but either way, the command is: $ git clone git://zynaddsubfx.git.sourceforge.net/gitroot/zynaddsubfx/zynaddsubfx zynaddsubfx After that it should be checked out to folder zynaddsubfx. For changing to the experimental branch: $ git checkout -b experimental origin/experimental And from there it's quite standard procedure for cmake projects. In the cmake system being used right now there are especially two significant variables, found in CMakeCache.txt One is OutputModule:STRING=jack Which is currently supported for jack and alsa And the other is GuiModule:STRING=qt Which can be qt, fltk or off. Note, for experimental, only qt is supported at this moment. If you switch to building master branch instead, then you probably want to change to fltk. Let me know if you're having problems with anything. Harald On Sun, Sep 27, 2009 at 10:40 PM, Abrolag <ab...@us...> wrote: > I thought I'd take a look at the experimental branch but can't seem to > make head nor tail of sourceforge and git :( > > What command to I need to use to get this. > > -- > Will J Godfrey > http://www.musically.me.uk > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Zynaddsubfx-user mailing list > Zyn...@li... > https://lists.sourceforge.net/lists/listinfo/zynaddsubfx-user > -- Harald Hvaal har...@gm... |
|
From: Abrolag <ab...@us...> - 2009-09-27 21:21:03
|
On Sun, 27 Sep 2009 22:58:38 +0200 Harald Hvaal <har...@gm...> wrote: > Sorry about the mess - the project page is supposed to list the > command for that, but due to recent changes in sourceforge's git > hosting the command listed there is not working. > It should be updated now, but either way, the command is: > $ git clone git://zynaddsubfx.git.sourceforge.net/gitroot/zynaddsubfx/zynaddsubfx > zynaddsubfx > > After that it should be checked out to folder zynaddsubfx. > For changing to the experimental branch: > > $ git checkout -b experimental origin/experimental > > And from there it's quite standard procedure for cmake projects. > In the cmake system being used right now there are especially two > significant variables, found in CMakeCache.txt > One is > OutputModule:STRING=jack > Which is currently supported for jack and alsa > > And the other is > GuiModule:STRING=qt > Which can be qt, fltk or off. Note, for experimental, only qt is > supported at this moment. > > If you switch to building master branch instead, then you probably > want to change to fltk. > > Let me know if you're having problems with anything. > > Harald Thanks for that. It's too late for me to try anything tonight :) but I'll see how I get on over the next couple of weekends. -- Will J Godfrey http://www.musically.me.uk |
|
From: Abrolag <ab...@us...> - 2009-09-28 18:37:18
|
On Sun, 27 Sep 2009 22:58:38 +0200 Harald Hvaal <har...@gm...> wrote: > Sorry about the mess - the project page is supposed to list the > command for that, but due to recent changes in sourceforge's git > hosting the command listed there is not working. > It should be updated now, but either way, the command is: > $ git clone git://zynaddsubfx.git.sourceforge.net/gitroot/zynaddsubfx/zynaddsubfx > zynaddsubfx > > After that it should be checked out to folder zynaddsubfx. > For changing to the experimental branch: > > $ git checkout -b experimental origin/experimental > > And from there it's quite standard procedure for cmake projects. > In the cmake system being used right now there are especially two > significant variables, found in CMakeCache.txt > One is > OutputModule:STRING=jack > Which is currently supported for jack and alsa > > And the other is > GuiModule:STRING=qt > Which can be qt, fltk or off. Note, for experimental, only qt is > supported at this moment. > > If you switch to building master branch instead, then you probably > want to change to fltk. > > Let me know if you're having problems with anything. > > Harald OK, tried that. Everything seemed to go OK, but I don't know if I was supposed to do some kind of re-fetch when doing the switch to experimental. Anyway, the compilation failed, as below :( g++ -O2 -Wall -g -DOS_LINUX -DALSAMIDIIN -DFFTW_VERSION_3 -DASM_F2I_YES -ggdb -DFLTK_GUI `fltk-config --cflags` -DOSSAUDIOOUT -c -o FilterUI.o FilterUI.cc fluid -c VirKeyboard.fl g++ -O2 -Wall -g -DOS_LINUX -DALSAMIDIIN -DFFTW_VERSION_3 -DASM_F2I_YES -ggdb -DFLTK_GUI `fltk-config --cflags` -DOSSAUDIOOUT -c -o VirKeyboard.o VirKeyboard.cc VirKeyboard.cc: In member function ‘void VirKeyboard::cb_Cval_i(Fl_Value_Slider*, void*)’: VirKeyboard.cc:252: error: no matching function for call to ‘Master::SetController(unsigned char&, int&, int)’ ../Misc/Master.h:80: note: candidates are: void Master::SetController(unsigned char, unsigned int, int, int) VirKeyboard.cc: In member function ‘void VirKeyboard::cb_pitchwheelroller_i(Fl_Roller*, void*)’: VirKeyboard.cc:304: error: no matching function for call to ‘Master::SetController(unsigned char&, MidiControllers, int)’ ../Misc/Master.h:80: note: candidates are: void Master::SetController(unsigned char, unsigned int, int, int) make[1]: *** [VirKeyboard.o] Error 1 make[1]: Leaving directory `/home/will/zynaddsubfx/src/UI' make: *** [all] Error 2 will@64studio:~/zynaddsubfx/src$ -- Will J Godfrey http://www.musically.me.uk |
|
From: james m. <ja...@jw...> - 2009-09-28 21:08:34
|
On 28/9/2009, "Abrolag" <ab...@us...> wrote: >On Sun, 27 Sep 2009 22:58:38 +0200 >Harald Hvaal <har...@gm...> wrote: > >> Sorry about the mess - the project page is supposed to list the >> command for that, but due to recent changes in sourceforge's git >> hosting the command listed there is not working. >> It should be updated now, but either way, the command is: >> $ git clone git://zynaddsubfx.git.sourceforge.net/gitroot/zynaddsubfx/zynaddsubfx >> zynaddsubfx >> >> After that it should be checked out to folder zynaddsubfx. >> For changing to the experimental branch: >> >> $ git checkout -b experimental origin/experimental >> >> And from there it's quite standard procedure for cmake projects. >> In the cmake system being used right now there are especially two >> significant variables, found in CMakeCache.txt >> One is >> OutputModule:STRING=jack >> Which is currently supported for jack and alsa >> >> And the other is >> GuiModule:STRING=qt >> Which can be qt, fltk or off. Note, for experimental, only qt is >> supported at this moment. >> >> If you switch to building master branch instead, then you probably >> want to change to fltk. >> >> Let me know if you're having problems with anything. >> >> Harald > >OK, tried that. Everything seemed to go OK, but I don't know if I was >supposed to do some kind of re-fetch when doing the switch to >experimental. Anyway, the compilation failed, as below :( > >g++ -O2 -Wall -g -DOS_LINUX -DALSAMIDIIN -DFFTW_VERSION_3 -DASM_F2I_YES >-ggdb -DFLTK_GUI `fltk-config --cflags` -DOSSAUDIOOUT -c -o >FilterUI.o FilterUI.cc fluid -c VirKeyboard.fl g++ -O2 -Wall -g >-DOS_LINUX -DALSAMIDIIN -DFFTW_VERSION_3 -DASM_F2I_YES -ggdb -DFLTK_GUI >`fltk-config --cflags` -DOSSAUDIOOUT -c -o VirKeyboard.o >VirKeyboard.cc VirKeyboard.cc: In member function âvoid >VirKeyboard::cb_Cval_i(Fl_Value_Slider*, void*)â: VirKeyboard.cc:252: >error: no matching function for call to âMaster::SetController(unsigned >char&, int&, int)â ../Misc/Master.h:80: note: candidates are: void >Master::SetController(unsigned char, unsigned int, int, int) >VirKeyboard.cc: In member function âvoid >VirKeyboard::cb_pitchwheelroller_i(Fl_Roller*, void*)â: >VirKeyboard.cc:304: error: no matching function for call to >âMaster::SetController(unsigned char&, MidiControllers, >int)â ../Misc/Master.h:80: note: candidates are: void >Master::SetController(unsigned char, unsigned int, int, int) make[1]: >*** [VirKeyboard.o] Error 1 make[1]: Leaving directory >`/home/will/zynaddsubfx/src/UI' make: *** [all] Error 2 >will@64studio:~/zynaddsubfx/src$ Hi Will, As you are building experimental - the experiment being a QT GUI - you need to change the GuiModule:STRING= line in CMakeCache.txt to GuiModule:STRING=qt ... Just checked, using the FLTK option fails for me too, but the QT build is successful. James. |
|
From: Abrolag <ab...@us...> - 2009-09-28 21:10:29
|
On Mon, 28 Sep 2009 22:08:11 +0100 (BST) "james morris" <ja...@jw...> wrote: > Hi Will, > > As you are building experimental - the experiment being a QT GUI - you > need to change the GuiModule:STRING= line in CMakeCache.txt to > > GuiModule:STRING=qt > > ... > > Just checked, using the FLTK option fails for me too, but the QT build is > successful. > > James. Hi James, There were a number of things I was doing wrong, but I've actually managed to try it now ! -- Will J Godfrey http://www.musically.me.uk |
|
From: Harald H. <har...@gm...> - 2009-09-28 21:11:11
|
On Mon, Sep 28, 2009 at 10:54 PM, Abrolag <ab...@us...> wrote: > > Ok, thanks got it working now. > > I take it experimental is really in it's infancy - seems to be just > wire-frame graphics, and I couldn't do a lot with it. Indeed so, the actual qt gui is taking a backseat and is these days more of a debug tool for the big backend changes than an actual alternative to the fltk gui. A few leftover bugs for now is that some controls have weird defaults, and the volume for the parts starts out too low to hear anything. > I also tried a build of the current git master which I found behaved > remarkably poorly with one of my more exotic patches. Release 2.4 (with > Mark's anti crackle patch) behaved far better. These days master is not really my specialty, so I asked Mark directly instead. Maybe he will post a reply. > Is it useful for me to do any other testing from time to time? At this stage for experimental, probably not. There isn't really any user interface to test at all, and the backend also needs much work before I would feel comfortable wasting other peoples time on finding bugs :) For master branch though, you could just continue doing what you just did - comment on stability, annoyances, etc. Sending this to the mailing list again in case someone has a comment. Oh, and for the other people reading this getting confused, I accidentally responded to his issue without reply to all, and we did a few private mails from there. -- Harald Hvaal har...@gm... |
|
From: Mark M. <mar...@gm...> - 2009-09-29 02:58:32
|
>> I also tried a build of the current git master which I found behaved >> remarkably poorly with one of my more exotic patches. Release 2.4 (with >> Mark's anti crackle patch) behaved far better. >These days master is not really my specialty, so I asked Mark directly >instead. Maybe he will post a reply. Just to clarify "behaved ... poorly" means that it was possible to get ZynAddSubFX to crackle and choke with JACK? Referring to my 'anti crackle' patch, I left that to sit in the jack-fix branch, as there are side effects for using it, but it should soon be obsolete. I would say that things should be running much more smoothly once I start importing the I/O from cal's work. I will say that I only have one thing to do before I lodge myself into the yoshimi integration branch for zynaddsubfx. I will be standardizing every last portion of the code style, I currently have a rough style guide and I should be able to get this done with soon. After I do this, I should not get out of the yoshimi branch for anything more than minor changes until I have a good portion of the I/O integrated. Once I have something substantial, I should be able to send a notice to the mailing list, as changes to this degree will need a good bit of testing to make sure that there were no mistakes. >> Is it useful for me to do any other testing from time to time? >At this stage for experimental, probably not. There isn't really any >user interface to test at all, and the backend also needs much work >before I would feel comfortable wasting other peoples time on finding >bugs :) >For master branch though, you could just continue doing what you just >did - comment on stability, annoyances, etc. I would say that unless otherwise noted, master should be the only 'stable' branch within git. Most of the time I create other branches to make sure the no instability from fixes/additions leak into the master branch. If you do have any issues that you find in master, then those should be noted, as master should represent the closest thing to another release in git. --Mark McCurry |
|
From: cal <ca...@gr...> - 2009-09-29 04:02:32
|
Mark McCurry wrote: > [ ... ] > Referring to my 'anti crackle' patch, I left that to sit in the jack-fix > branch, as there are side effects for using it, but it should soon be > obsolete. > I would say that things should be running much more smoothly once I > start importing the I/O from cal's work. Can I ask what your starting point is for that? The organisation of the git repository leaves me seriously bewidered, but if I know where you're starting from, I thought I might tag along just for fun :). cheers, Cal |
|
From: Abrolag <ab...@us...> - 2009-09-29 19:01:42
|
On Mon, 28 Sep 2009 22:58:18 -0400 Mark McCurry <mar...@gm...> wrote: > Just to clarify "behaved ... poorly" means that it was possible to get > ZynAddSubFX to crackle and choke with JACK? Yes quite severely. Holes in the output on every chord change. Also processor usage was about 80% whereas on all other versions it was about 25% This was working with an external MIDI keyboard connected via Jack/Alsa and no other audio kit running at all. I was using Master Synth Low and playing a falling three note chord progression C, G, Bb, F (this only changes two notes at a time). E G C D G B D F Bb C F A -- Will J Godfrey http://www.musically.me.uk |
|
From: Mark M. <mar...@gm...> - 2009-10-01 03:20:33
|
>Can I ask what your starting point is for that? The organisation of the git >repository leaves me seriously bewidered, but if I know where you're starting >from, I thought I might tag along just for fun :). Hopefully this clarifies git. Current Git Organization: master - primary stable branch experimental - branch for work on controls/Qt newXML - recently used to renovate XMLwrapper later used for enhancing/modifying the default format of .xmz yoshimi - for integrating yoshimi modifications strings - a quickly made branch for me to see a what-if scenario about replacement of cstrings/static structures (needs testing) jack_fix - Branch off master to fix jack driver issues (obsolete) cxxTesting - I am fairly sure that this is one that is long obsolete, but I might be wrong release - Branch that was used for last minute cleanups for previous release (it is inactive) When working with any yoshimi integration, I will be in the branch of the same name. Within that branch, I should have things all up-to-date from the master branch, so it can be easily merged into master when it is ready. >> Just to clarify "behaved ... poorly" means that it was possible to get >> ZynAddSubFX to crackle and choke with JACK? >Yes quite severely. Holes in the output on every chord change. I hope that the work that cal has done will seal a good number of these holes, as it was shown that a small change in the jack output driver could do quite a bit of good. I would say that in most cases the holes are the result of flaws in the threading code that is getting actively reworked. >processor usage was about 80% whereas on all other versions it was >about 25% Hoping between the two versions I have not seen that great of a difference, and through profiling I only come across the expected cpu time users for the most recent copy. (like processing for SUBnote (which has remained unchanged for quite some time)) I can see many reasons for the output holes, but few for the cpu usage. I know of one change within git vs 2.4.0, the optimization level. I was fairly sure that -O6 did not do too much over -O2 and -O2 was a good bit faster, so I modified the default optimization. If you want to see if that is a source of cpu time, just change the optimization at the top of the Makefile within src/ It did not seem to give me too significant of a change, but this is one of those things that can vary quite a bit with gcc version. --Mark McCurry |
|
From: cal <ca...@gr...> - 2009-10-01 04:54:46
|
Mark McCurry wrote:
> >Can I ask what your starting point is for that? The organisation of
> the git
> >repository leaves me seriously bewidered, but if I know where you're
> starting
> >from, I thought I might tag along just for fun :).
> Hopefully this clarifies git.
Sure does, thanks.
> Current Git Organization:
> master - primary stable branch
> experimental - branch for work on controls/Qt
> newXML - recently used to renovate XMLwrapper later used for
> enhancing/modifying the default format of .xmz
> yoshimi - for integrating yoshimi modifications
> strings - a quickly made branch for me to see a what-if scenario about
> replacement of cstrings/static structures (needs testing)
> jack_fix - Branch off master to fix jack driver issues (obsolete)
> cxxTesting - I am fairly sure that this is one that is long obsolete,
> but I might be wrong
> release - Branch that was used for last minute cleanups for previous
> release (it is inactive)
>
> When working with any yoshimi integration, I will be in the branch of
> the same name.
> Within that branch, I should have things all up-to-date from the master
> branch, so it can be easily merged into master when it is ready.
>
> >> Just to clarify "behaved ... poorly" means that it was possible to get
> >> ZynAddSubFX to crackle and choke with JACK?
> >Yes quite severely. Holes in the output on every chord change.
> I hope that the work that cal has done will seal a good number of these
> holes,
> as it was shown that a small change in the jack output driver could do
> quite a bit of good.
> I would say that in most cases the holes are the result of flaws in the
> threading code that is getting actively reworked.
On that subject, the jack source comment for jack_set_process_callback() reads
{{{
* The code in the supplied function must be suitable for real-time
* execution. That means that it cannot call functions that might
* block for a long time. This includes malloc, free, printf,
* pthread_mutex_lock, sleep, wait, poll, select, pthread_join,
* pthread_cond_wait, etc, etc. See
* http://jackit.sourceforge.net/docs/design/design.html#SECTION00411000000000000000
* for more information.
}}}
Currently, Zyn flaunts that requirement big time, which is _the_ reason it
crackles and farts on jack io.
> >processor usage was about 80% whereas on all other versions it was
> >about 25%
> Hoping between the two versions I have not seen that great of a
> difference, and through profiling
> I only come across the expected cpu time users for the most recent copy.
> (like processing for SUBnote (which has remained unchanged for quite
> some time))
> I can see many reasons for the output holes, but few for the cpu usage.
>
> I know of one change within git vs 2.4.0, the optimization level.
> I was fairly sure that -O6 did not do too much over -O2 and -O2 was a
> good bit faster, so I modified the default optimization.
> If you want to see if that is a source of cpu time, just change the
> optimization at the top of the Makefile within src/
> It did not seem to give me too significant of a change, but this is one
> of those things that can vary quite a bit with gcc version.
You're kidding yourself here. Yoshi does feature a significant reduction in cpu
usage (like 10 - 20 or more percent reduction), and it comes from the application
of some very simple but widespread processing optimisations. Across the range of
-O0 to -O999 you'll be lucky to see a variation of 0.0000000001 percent in Zyn cpu
usage, or speed for that matter. Chris Cannam of Rosegarden fame gave some
helpful advice on LAU recently,
<http://lists.linuxaudio.org/pipermail/linux-audio-user/2009-August/062159.html>
Good old <http://freshmeat.net/articles/gcc-myths-and-facts> is also worth a read.
|
|
From: Mark M. <mar...@gm...> - 2009-10-02 18:22:01
|
>Currently, Zyn flaunts that requirement big time, which is _the_ reason it >crackles and farts on jack io. Yes, JACK does not like to wait and ZynAddSubFX breaks this contract big time. In order to resolve this, I would say that one would need to make jobs for the backend, such that they can be executed outside of the main master::AudioOut loop and master->mutex needs to be severely deprecated. If I recall, you did some work to create a ring buffer for input events in a separate thread to avoid some of the current issues. Some of the work in experimental is going in this direction. The controls are being made to be atomic, so you don't need to use master->mutex to work with them and there is a job system that has received some development that could be used to move stuff out of the master::AudioOut loop. The job system is currently executed in the main loop, but due to the implementation it should not be too difficult to move that outside of the primary thread. >You're kidding yourself here That is what I would think, but I just don't see anything that has changed so much between 2.2.1 and now that it could result in the cpu usage differences that Will Godfrey points out, so I am left guessing what all that extra cpu time is doing. (nothing that I have seen creates differences in the order of magnitude were reported) >you'll be lucky to see a variation of 0.0000000001 percent in Zyn cpu usage I cannot speak for the exact effect of compiler flags on Zyn, but I will say that in the past I have seen worlds of difference in the run time on programs going from no optimization to -O2. (-O3's benefits are plenty debatable) (of course this could be explained as a poor original code, but optimizations do have an effect on programs in general) >Yoshi does feature a significant reduction in cpu usage Which optimizations are you refering to? I know in one of the previous times I checked your version, there was some new code for denormals, but I am not sure if that is what you are referencing. (from what I have read, denormals can use significant cpu amounts on some processors) --Mark McCurry |
|
From: cal <ca...@gr...> - 2009-10-02 19:17:03
|
Mark McCurry wrote:
> >Currently, Zyn flaunts that requirement big time, which is _the_ reason it
> >crackles and farts on jack io.
> Yes, JACK does not like to wait and ZynAddSubFX breaks this contract big
> time.
> In order to resolve this, I would say that one would need to make jobs
> for the backend, such that they can be executed outside of the main
> master::AudioOut loop and master->mutex needs to be severely deprecated.
> If I recall, you did some work to create a ring buffer for input events
> in a separate thread to avoid some of the current issues.
No on the audio, yes on the midi. If you eliminate the grotesque
GetAudioOutSamples() hackery in Master, jack audio actually works very well
driving directly to Master's AudioOut(). In yoshi, there's a subtle safeguard.
The process callback only makes three attempts to acquire the mutex lock. If
it gets the lock, all is well and life proceeds as it should. If it fails to
get the lock, then what gets fed to jack audio is the same samples left in the
buffer from the last cycle. The theory here was that repeating a buffer of
samples occasionally might be a softer error than injecting a buffer full of
silence, and certainly less disruptive than overstaying in the callback. In
practise this seems to work well enough. With the current setup, I haven't seen
it miss the lock yet. I suspect it does happen, but I haven't noticed it either
audibly or in logging. With earlier versions I was seeing a couple every few
minutes or so. The occurrence rate now would be N per hour, certainly not N
per second.
Midi is different, kinda slow. Your control work sounds promising in this area.
A simple ringbuffer setup works well. As far as I can tell, the only messages
Zyn cares about are four bytes or less, so it's light, fast enough, and jack's
ringbuffer is well proven, solid technology.
> Some of the work in experimental is going in this direction.
> The controls are being made to be atomic, so you don't need to use
> master->mutex to work with them and there is a job system that has
> received some development that could be used to move stuff out of the
> master::AudioOut loop.
Record and note dumping for example.
> The job system is currently executed in the main loop, but due to the
> implementation it should not be too difficult to move that outside of
> the primary thread.
Sounds promising.
[ ... ]
> Which optimizations are you refering to?
> I know in one of the previous times I checked your version, there was
> some new code for denormals, but I am not sure if that is what you are
> referencing. (from what I have read, denormals can use significant cpu
> amounts on some processors)
Zyn does what it does by looping through the buffer performing N floating
point operations on every sample, so loop unrolling isn't going to have
much effect. There's a whole lot of places where the buffer is cleared by
a loop doing = 0.0 assignments. A simple memset() does the same thing a
whole lot quicker and lighter. There's enough of them in there to make a
significant difference with more complex patches. There's a very small
number of places where memcpy() can be applied too.
Denormals are strangely interesting, and alarmingly destructive. Yoshi
currently contains the remnants of a few of my experiments, but I'm
starting to think the only one in there now that counts for much is
set_DAZ_and_FTZ().
cheers.
|
|
From: cal <ca...@gr...> - 2009-10-02 20:27:05
|
One more thing I meant to mention... very early on I had jack midi as a distinct
client separate to jack audio, and you commented that it seemed a good idea. I
thought so too at the time. On LAU, Paul Davis responded to that notion with
>> you've just destroyed the entire goal of JACK MIDI :)
so I felt a need to reconsider my position. One client connection and light
processing in the callback is the jack way.
cheers.
|
|
From: Mark M. <mar...@gm...> - 2009-10-04 14:53:46
|
> If it fails to >get the lock, then what gets fed to jack audio is the same samples left in the >buffer from the last cycle. Sounds like a good compromise. >Midi is different, kinda slow. Your control work sounds promising in this area. This is a the area that will benefit the most from the control work. As it gets integrated, zyn will be able to work much more cleanly with midi and instead of being limited to the hardcoded midi links, the user can make them as needed. It should be fairly lightweight too. >Record and note dumping for example. Yes, these could be moved outside of the main loop, but I am not 100% decided if recording should be treated as something other than an output driver. I will need to read through your updated code to see if it could fit the model that you have laid out though. >A simple memset() does the same thing a >whole lot quicker and lighter... Good point, I cannot think of a good reason why this is not already done in the codebase. I will certainly make sure to put these functions to good use. >This then compiled and ran without the enormous CPU usage, so maybe I >was previously unlucky and caught it between versions or something. I am not too sure what could have happened, but it is good to know that zyn is behaving sanely on your machine now. >One client connection and light >processing in the callback is the jack way. That seems to explain some of the recent changes to your system that I have seen. --Mark McCurry |
|
From: cal <ca...@gr...> - 2009-10-05 03:21:11
|
Mark McCurry wrote: > [ ... ] > >Midi is different, kinda slow. Your control work sounds promising in > this area. > This is a the area that will benefit the most from the control work. > As it gets integrated, zyn will be able to work much more cleanly with > midi and instead > of being limited to the hardcoded midi links, the user can make them as > needed. > It should be fairly lightweight too. I'm not at all clear what you mean by that, but I am curious. > >Record and note dumping for example. > Yes, these could be moved outside of the main loop, but I am not 100% > decided > if recording should be treated as something other than an output driver. > I will need to read through your updated code to see if it could fit the > model that you have laid out though. Record comes with some tricky problems. Disk io absolutely _has_ to be kept out of the sound generation cycle so you're looking at some serious buffering. One idea I've started playing with is writing to a fifo from MusicIO.cpp, with yet another thread reading the fifo and writing to disk. I'm not overly optimistic that it'll be able to keep up, but I intend to explore it a bit further. If the record function wasn't so useful on occasions, you'd have to say "Way too hard, handle it outside the synth!". cheers. |
|
From: Abrolag <ab...@us...> - 2009-10-02 20:09:29
|
On Wed, 30 Sep 2009 23:20:10 -0400 Mark McCurry <mar...@gm...> wrote: > >> Just to clarify "behaved ... poorly" means that it was possible to get > >> ZynAddSubFX to crackle and choke with JACK? > >Yes quite severely. Holes in the output on every chord change. > I hope that the work that cal has done will seal a good number of these > holes, > as it was shown that a small change in the jack output driver could do quite > a bit of good. > I would say that in most cases the holes are the result of flaws in the > threading code that is getting actively reworked. > > >processor usage was about 80% whereas on all other versions it was > >about 25% > Hoping between the two versions I have not seen that great of a difference, > and through profiling > I only come across the expected cpu time users for the most recent copy. > (like processing for SUBnote (which has remained unchanged for quite some > time)) > I can see many reasons for the output holes, but few for the cpu usage. > > I know of one change within git vs 2.4.0, the optimization level. > I was fairly sure that -O6 did not do too much over -O2 and -O2 was a good > bit faster, so I modified the default optimization. > If you want to see if that is a source of cpu time, just change the > optimization at the top of the Makefile within src/ > It did not seem to give me too significant of a change, but this is one of > those things that can vary quite a bit with gcc version. > > --Mark McCurry Well, I tried various things to no avail, but this evening I decided to wipe the entire directory and re-fetch the current git version. This then compiled and ran without the enormous CPU usage, so maybe I was previously unlucky and caught it between versions or something. I still have the crackles, but nowhere near as bad as when I was winding CPU usage up to 80% -- Will J Godfrey http://www.musically.me.uk |
Thanks for helping keep SourceForge clean.
X