Thread: [Bluemusic-users] assigning widgets values to i-rate variables
Brought to you by:
kunstmusik
From: Atte A. J. <att...@gm...> - 2008-10-20 08:02:57
Attachments:
api.blue
|
Hi I realized that most of my stuff doesn't work with the API-way, at least some type stuff needs to be fixed. Consider the following, simple BSB instrument: --- blue begin ------------ if (p4 != 0) then kfreq = p4 else kfreq = <freq> endif if (p5 != 0) then ilength = p5 else ilength = i(<length>) endif aampenv linseg 0, .01, 1, ilength, 1, .01, 0 aout oscili 20000, kfreq, git_instr_test_sine aout = aout * aampenv blueMixerOut aout, aout --- blue end ----------------- This will work through the API, but not the old way, because in that case <length> expands to an integer, resulting in an error like: error: illegal opcod from expr anal, line 62: ilength = i(0.1690000147) So, I'm hoping for good ways if doing stuff like this, esp assigning widgets values to i-rate variables, in a way that works with the old/new style blue. NB: Attached is the simple .blue with the above instrument... -- Atte http://atte.dk http://modlys.dk |
From: Atte A. J. <att...@gm...> - 2008-10-20 08:06:26
|
Atte André Jensen wrote: > I realized that most of my stuff doesn't work with the API-way, at least > some type stuff needs to be fixed. Just to clarify: I mean it's *my* code that needs to be changed in order to work with the API. It came out a bit like I felt something in blue needs fixing, which wasn't my intention. -- Atte http://atte.dk http://modlys.dk |
From: Atte A. J. <att...@gm...> - 2008-10-20 21:26:13
Attachments:
api.blue
|
Atte André Jensen wrote: > So, I'm hoping for good ways if doing stuff like this, esp assigning > widgets values to i-rate variables, in a way that works with the old/new > style blue. I'm still working on a solution, and came upt with something that partly works (and is ugly): if (p5 != 0) then ilength = p5 else klength = <length> ilength = i(klength) endif However as the attached .blue shows, there's a problem, and I simply can't get my head around it. Why is the first beep short (ilength seems to be 0, according to the csound output), I'd expect it to be long like the other three?? Any input appreciated! -- Atte http://atte.dk http://modlys.dk |
From: Atte A. J. <att...@gm...> - 2008-10-24 09:28:15
|
Steven Yi wrote: > Okay, I thing we are in agreement here. If anyone else has an issue, > please let me know, Well, I (as I wrote in another mail) hacked up one of my projects to use the API. I found it performed badly (with glitches) which might just be my setup. Also, one could just keep using the non-API way with appropriate changes to the instruments. More importantly I found that alot of the BSB's doesn't work with widgets values being expanded as k-rate variables. A quick fix might be to set them to non-automatable, but it's gonna take quite some work to get everything in blueShare working again. -- Atte http://atte.dk http://modlys.dk |
From: Steven Y. <ste...@gm...> - 2008-10-21 14:12:06
|
Hi Atte, Sorry for the delay, I'm away for work at a developer conference so am slow for emails until I get back home Wednesday night. For this project, the bug is a bit subtle, but you have an assignment to a k-rate variable within an irate if-then-else. That conditional is i-rate because the comparison is done between constants (p5 and 0). To fix, use: klength init <length> instead, as init is an i-time opcode, versus = which will change its rate depending on type of output arg (I'd have to look at source code exactly to know the exact details of how = chooses what rate). Otherwise, I would have done the same regarding assigning to krate variable first. Cheers! steven On Mon, Oct 20, 2008 at 2:25 PM, Atte André Jensen <att...@gm...> wrote: > Atte André Jensen wrote: > >> So, I'm hoping for good ways if doing stuff like this, esp assigning >> widgets values to i-rate variables, in a way that works with the old/new >> style blue. > > I'm still working on a solution, and came upt with something that partly > works (and is ugly): > > if (p5 != 0) then > ilength = p5 > else > klength = <length> > ilength = i(klength) > endif > > However as the attached .blue shows, there's a problem, and I simply can't > get my head around it. Why is the first beep short (ilength seems to be 0, > according to the csound output), I'd expect it to be long like the other > three?? > > Any input appreciated! > > -- > Atte > > http://atte.dk http://modlys.dk > > <blueData version='0.124.2'> > <projectProperties> > <title></title> > <author>Atte AndrÃ(c) Jensen (atte.dk), 2008</author> > <notes></notes> > <sampleRate>44100</sampleRate> > <ksmps>100</ksmps> > <channels>2</channels> > <diskSampleRate>44100</diskSampleRate> > <diskKsmps>1</diskKsmps> > <diskChannels>2</diskChannels> > <useAudioOut>true</useAudioOut> > <useAudioIn>false</useAudioIn> > <useMidiIn>false</useMidiIn> > <useMidiOut>false</useMidiOut> > <noteAmpsEnabled>false</noteAmpsEnabled> > <outOfRangeEnabled>true</outOfRangeEnabled> > <warningsEnabled>false</warningsEnabled> > <benchmarkEnabled>false</benchmarkEnabled> > <advancedSettings></advancedSettings> > <completeOverride>false</completeOverride> > <fileName></fileName> > <askOnRender>false</askOnRender> > <diskNoteAmpsEnabled>true</diskNoteAmpsEnabled> > <diskOutOfRangeEnabled>true</diskOutOfRangeEnabled> > <diskWarningsEnabled>true</diskWarningsEnabled> > <diskBenchmarkEnabled>true</diskBenchmarkEnabled> > <diskAdvancedSettings></diskAdvancedSettings> > <diskCompleteOverride>false</diskCompleteOverride> > <diskAlwaysRenderEntireProject>false</diskAlwaysRenderEntireProject> > <csladspaSettings> > <name/> > <maker/> > <uniqueId>0</uniqueId> > <copyright/> > <portDefinitionList/> > <enabled>false</enabled> > </csladspaSettings> > </projectProperties> > <arrangement> > <instrumentAssignment arrangementId='test' isEnabled='true'> > <instrument type='blue.orchestra.BlueSynthBuilder' editEnabled='true'> > <name>test</name> > <comment></comment> > <globalOrc>git_instr_test_sine ftgen 0, 0, 16384, 10, > 1</globalOrc> > <globalSco/> > <instrumentText>if (p4 != 0) then > kfreq = p4 > else > kfreq = <freq> > endif > > > if (p5 != 0) then > ilength = p5 > else > klength = <length> > ilength = i(klength) > endif > > printk .1, ilength > > aampenv linseg 0, .01, 1, ilength, 1, .01, 0 > aout oscili 20000, kfreq, git_instr_test_sine > aout = aout * aampenv > > blueMixerOut aout, aout</instrumentText> > <graphicInterface editEnabled='false'> > <uniqueNameManager nameIndex='-1' defaultPrefix='bsbObj'/> > <bsbObject type='blue.orchestra.blueSynthBuilder.BSBHSlider'> > <objectName>freq</objectName> > <x>120</x> > <y>151</y> > <automationAllowed>true</automationAllowed> > <minimum>20.0</minimum> > <maximum>20000.0</maximum> > <resolution>0.1</resolution> > <value>1828.8</value> > <sliderWidth>500</sliderWidth> > <randomizable>true</randomizable> > </bsbObject> > <bsbObject type='blue.orchestra.blueSynthBuilder.BSBHSlider'> > <objectName>length</objectName> > <x>121</x> > <y>191</y> > <automationAllowed>true</automationAllowed> > <minimum>0.0</minimum> > <maximum>1.0</maximum> > <resolution>0.0010</resolution> > <value>0.507</value> > <sliderWidth>500</sliderWidth> > <randomizable>true</randomizable> > </bsbObject> > <bsbObject type='blue.orchestra.blueSynthBuilder.BSBLabel'> > <objectName></objectName> > <x>684</x> > <y>159</y> > <label>Freq</label> > </bsbObject> > <bsbObject type='blue.orchestra.blueSynthBuilder.BSBLabel'> > <objectName></objectName> > <x>678</x> > <y>195</y> > <label>Length</label> > </bsbObject> > </graphicInterface> > <bsbParameterList> > <parameter uniqueId='290505855' name='freq' label='' min='20.0' > max='20000.0' resolution='0.1' automationEnabled='false' value='1828.8'> > <line name='' version='2' max='20000.0' min='20.0' > resolution='0.1' color='-8355712' rightBound='false' > endPointsLinked='false'> > <linePoint x='0.0' y='1828.8'/> > </line> > </parameter> > <parameter uniqueId='470137866' name='length' label='' min='0.0' > max='1.0' resolution='0.0010' automationEnabled='false' value='0.507'> > <line name='' version='2' max='1.0' min='0.0' resolution='0.0010' > color='-8355712' rightBound='false' endPointsLinked='false'> > <linePoint x='0.0' y='0.507'/> > </line> > </parameter> > </bsbParameterList> > <presetGroup name='Presets'/> > <opcodeList/> > </instrument> > </instrumentAssignment> > </arrangement> > <mixer> > <enabled>true</enabled> > <extraRenderTime>0.0</extraRenderTime> > <channelList list='channels'> > <channel> > <name>test</name> > <outChannel>Master</outChannel> > <level>0.0</level> > <muted>false</muted> > <solo>false</solo> > <effectsChain bin='pre'/> > <effectsChain bin='post'/> > <parameter uniqueId='280939627' name='Volume' label='dB' min='-96.0' > max='12.0' resolution='-1.0' automationEnabled='false' value='0.0'> > <line name='' version='2' max='12.0' min='-96.0' resolution='-1.0' > color='-8355712' rightBound='false' endPointsLinked='false'> > <linePoint x='0.0' y='0.0'/> > </line> > </parameter> > </channel> > </channelList> > <channelList list='subChannels'/> > <channel> > <name>Master</name> > <outChannel>Master</outChannel> > <level>0.0</level> > <muted>false</muted> > <solo>false</solo> > <effectsChain bin='pre'/> > <effectsChain bin='post'/> > <parameter uniqueId='278849771' name='Volume' label='dB' min='-96.0' > max='12.0' resolution='-1.0' automationEnabled='false' value='0.0'> > <line name='' version='2' max='12.0' min='-96.0' resolution='-1.0' > color='-8355712' rightBound='false' endPointsLinked='false'> > <linePoint x='0.0' y='0.0'/> > </line> > </parameter> > </channel> > </mixer> > <tables></tables> > <soundObjectLibrary/> > <globalOrcSco> > <globalOrc></globalOrc> > <globalSco></globalSco> > </globalOrcSco> > <opcodeList/> > <liveData> > <commandLine>csound -Wdo devaudio -L stdin</commandLine> > <commandLineEnabled>false</commandLineEnabled> > <commandLineOverride>false</commandLineOverride> > </liveData> > <soundObject type='blue.soundObject.PolyObject'> > <subjectiveDuration>2.0</subjectiveDuration> > <startTime>0.0</startTime> > <name>root</name> > <backgroundColor>-10066279</backgroundColor> > <timeBehavior>0</timeBehavior> > <noteProcessorChain/> > <isRoot>true</isRoot> > <pixelSecond>64</pixelSecond> > <defaultHeightIndex>0</defaultHeightIndex> > <snapEnabled>true</snapEnabled> > <snapValue>1.0</snapValue> > <timeDisplay>0</timeDisplay> > <timeUnit>4</timeUnit> > <soundLayer name='' muted='false' solo='false' heightIndex='0'> > <noteProcessorChain/> > <soundObject type='blue.soundObject.GenericScore'> > <subjectiveDuration>4.0</subjectiveDuration> > <startTime>0.0</startTime> > <name>GenericScore</name> > <backgroundColor>-12566464</backgroundColor> > <timeBehavior>1</timeBehavior> > <repeatPoint>-1.0</repeatPoint> > <noteProcessorChain/> > <score>i"test" 0 1</score> > </soundObject> > </soundLayer> > </soundObject> > <scratchPadData> > <isWordWrapEnabled>true</isWordWrapEnabled> > <scratchText/> > </scratchPadData> > <noteProcessorChainMap/> > <renderStartTime>0.0</renderStartTime> > <renderEndTime>4.0</renderEndTime> > <markersList/> > <loopRendering>false</loopRendering> > <tempo> > <enabled>false</enabled> > <visible>false</visible> > <line name='' version='2' max='240.0' min='30.0' resolution='-1.0' > color='-8355712' rightBound='false' endPointsLinked='false'> > <linePoint x='0.0' y='60.0'/> > </line> > </tempo> > </blueData> > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Bluemusic-users mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-users > > |
From: Atte A. J. <att...@gm...> - 2008-10-21 21:20:59
|
Steven Yi wrote: > klength init <length> I tried that. It works great without the api, but with the api enabled it fails (I'm trying to write BSBs that would work both with and without the api): error: input arg 'gk_blue_auto1' of type k not allowed when expecting i, line 66: klength init gk_blue_auto1 This is because <length> expands to a k-rate variable with the api (if I understand correctly), while without it expands to a simple float. -- Atte http://atte.dk http://modlys.dk |
From: Steven Y. <ste...@gm...> - 2008-10-28 15:49:47
|
Hi Atte, Sorry it's taken a while for things to settle down enough for me to take a look. I think I have modified the code correctly so that automatables now always generate k-rate signals. I've placed a version at: http://www.kunstmusik.com/blue_0.124.3_installer.jar http://www.kunstmusik.com/blue_0.124.3.zip Could you take a look (or update from CVS) and see if it works for you? I need to review the blue documentation to make sure that it reflects the new behavior and puts in a note about backwards compatibility. Thanks! steven On Fri, Oct 24, 2008 at 9:40 AM, Atte André Jensen <att...@gm...> wrote: > Steven Yi wrote: > >> I've gotten glitches too and have not yet figured out why, though I am >> still looking at it. > > So what you're saying is that using the API is not a 100% viable > solution ATM, but that it has potential, and that we should strive for > ironing out the bumps and glitches to make it work as well as "the old way"? > > No problem with me :-) I was more worried if I was the only one getting > strange behavior. > > BTW: I got so fed up with strangeness under ubuntu today that I > installed debian on a second partition. Some things are not working yet, > but I will setup blue etc and report back on how things are performing > there... > > -- > Atte > > http://atte.dk http://modlys.dk > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Bluemusic-users mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-users > |
From: Atte A. J. <att...@gm...> - 2008-10-24 05:23:54
|
Atte André Jensen wrote: > I tried that. It works great without the api, but with the api enabled > it fails (I'm trying to write BSBs that would work both with and without > the api): > > error: input arg 'gk_blue_auto1' of type k not allowed when expecting > i, line 66: > klength init gk_blue_auto1 > > This is because <length> expands to a k-rate variable with the api (if I > understand correctly), while without it expands to a simple float. Note: I haven't been able to make any progress with this, actually I'm currently working without the API just to get some work done. So I'm still hoping on input on this: How can I use a widget's value as i-rate variable with code that works both with and without the API? Steven, how do you go about this? -- Atte http://atte.dk http://modlys.dk |
From: Atte A. J. <att...@gm...> - 2008-10-28 21:40:20
|
Steven Yi wrote: > Could you take a look (or update from CVS) and see if it works for you? That seems to work great, thanks. However now I'm no longer able to run without glitches even without the API. I now have to use -b 512 and -B 1024, isn't that un-reasonably large buffers? When looking at the output of htop, I don't see any process running with priority 80 eventhough I have --sched=80 in my advanced options. I'm wondering if running with the API means that csound inherits the priority of blue? If possible it would be better to have only csound run with high priority to make it imune to rendering in the gui. In any case I'd be most interrested in hearing others thoughts, findings, experiences and knowledge on this, esp under linux. NB: It was extremely cool to move sliders in my instruments and hearing the result in realtime. Working through the API is for sure the future of blue. -- Atte http://atte.dk http://modlys.dk |
From: Steven Y. <ste...@gm...> - 2008-10-24 06:15:30
|
Hi Atte, I actually have never come across this in my own code as I don't use i(kvar) for the things I need to do. I am not sure there is a csound-only solution; perhaps the best thing might be for me to remove generation as constant altogether when a widget is set as automatable, and use the constant generation only in the case when it is not automatable. This may change behavior for older projects though, but the workaround would be clear. In my head that seems to make sense: "Because this object is set to be automatable, this means it has the potential to change at krate, therefore your instrument code must be able to use krate var". If it's not automatable, it's saying "This going to be a constant value". Anyone have thoughts on this? (Maybe this could be fine if we setup a "Backwards Compatibility" page in the manual that describes situations where backwards compatibility may be broken and what to do?) Thanks! steven On Thu, Oct 23, 2008 at 10:23 PM, Atte André Jensen <att...@gm...> wrote: > Atte André Jensen wrote: > >> I tried that. It works great without the api, but with the api enabled >> it fails (I'm trying to write BSBs that would work both with and without >> the api): >> >> error: input arg 'gk_blue_auto1' of type k not allowed when expecting >> i, line 66: >> klength init gk_blue_auto1 >> >> This is because <length> expands to a k-rate variable with the api (if I >> understand correctly), while without it expands to a simple float. > > Note: I haven't been able to make any progress with this, actually I'm > currently working without the API just to get some work done. So I'm > still hoping on input on this: > > How can I use a widget's value as i-rate variable with code that works > both with and without the API? > > Steven, how do you go about this? > > -- > Atte > > http://atte.dk http://modlys.dk > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Bluemusic-users mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-users > |
From: Atte A. J. <att...@gm...> - 2008-10-24 06:30:37
|
Steven Yi wrote: > I actually have never come across this in my own code as I don't use > i(kvar) for the things I need to do. I am not sure there is a > csound-only solution; perhaps the best thing might be for me to remove > generation as constant altogether when a widget is set as automatable, > and use the constant generation only in the case when it is not > automatable. This may change behavior for older projects though, but > the workaround would be clear. I think that might be a good solution. Would there be a slight performance overhead (due to automatable widgets being k-rate and not i-rate), or? In any case it would be very, very small, and it makes blues behavior more clear. Backwards compatibility is always a good thing, but if it's holding new directions for the software back, it could be necessary to break it. -- Atte http://atte.dk http://modlys.dk |
From: Atte A. J. <att...@gm...> - 2008-10-29 08:06:52
Attachments:
Screenshot-1.png
|
Steven Yi wrote: > Glad that works! I'm going to update documentation will issue a > release tonight. Great! This means that we can start working on new versions of stuff in blueShare. Should I start making notes about which things work, and which doesn't? I'm not sure that all authors of the affected stuff in blueShare are active, should we (I) hotfix their code and submit API versions of the instruments/fx in question? > As for running with the API, I don't think you can up the priority as > it is in the same process as blue. I may be able to try increasing the > priority in Java, but I am not sure how much of a difference that will > make. I just tried setting the render thread to max priority, but I > don't know if it makes a difference. It still won't be like upping > the priority of the process using sched. (The code is now in CVS and > will be in the release build I do tonight.) I tried cvs, and it doesn't make any difference. > I'm not sure of any other thing I can do to increase the priority. On > Linux, you might be able to increase the priority of the java process > that runs blue as a whole, though I don't know how the system will > react to that. I was able to make blue run glitch free with the API with -B256 -b45 () by doing "sudo chrt -f -p 80 17783", where 17783 is the pid of the java process. This is good news, as it means there must be a way to get things running smoothly. However in itself it is not a viable solution since the process that needs this seems to be spawn when rendering. This means I have to start the render, look at the output of htop, and issue the command with the correct pid. I attached a screenshot of htop after the changed priority. So I think we need to make changes to the way blue spawns the thread, doing something like this automatically. BTW: I see two java processes taking up cpu when rendering with blue, one seems to be the main blue thread, since it keeps it's pid throughout a blue session, the other one I suspect is the one spawned when rendering. I also tried changing the pid of the main thread, but that doesn't seem to be inherited by the render thread. There are also quite alot of other threads looking similar (in the screenshot I count 9 in all), but taking up much less cpu. Could you elaborate a bit on why all these threads are there? Where in the code is the spawning of the render thread happening? I'd like to take a look at the code and fool around with it a bit, maybe I can come up with something... -- Atte http://atte.dk http://modlys.dk |
From: Steven Y. <ste...@gm...> - 2008-10-30 05:20:44
|
HI Atte, Regarding blueShare, yes, I would recommend updating items in blueShare. I've been to swamped to even update my own library of effects and instruments, but have had a note to do so for over a month! As for fixing other authors' stuff, I'm not sure what's the most proper thing to do. Anyone could always download the instrument or effect, update it, and upload it, giving credit to the original author, and I could maybe create a deprecated category and move any instrument that gets updated to that category. Ultimately, it'd be nice to create newer blueShare that allowed versioning and collaboration, but that seems like a bit more work than I have time for unfortunately. If someone who has Ruby-on-Rails experience though wants to take a stab at it, I could always work on the Java part within blue. Regarding Java threads, Java usually has a number of threads running when running graphical software. I think one is for garbage collection, one is an event queue for the UI Toolkit, another for some other UI function, etc. Regarding the thread that gets created for Csound rendering, I do not think there is any way to get a PID for it in Java alone; the Thread class has an ID but I think it is an internal identifier and not one related to PID. The code for rendering in Thread is contained in either the blue.render.APIRunner class or blue.render.CommandlineRunner class, within the src/main/blue/render folder. If you come up with any good ieas I'd love to hear them! steven On Wed, Oct 29, 2008 at 1:06 AM, Atte André Jensen <att...@gm...> wrote: > Steven Yi wrote: > >> Glad that works! I'm going to update documentation will issue a >> release tonight. > > Great! This means that we can start working on new versions of stuff in > blueShare. Should I start making notes about which things work, and which > doesn't? > > I'm not sure that all authors of the affected stuff in blueShare are active, > should we (I) hotfix their code and submit API versions of the > instruments/fx in question? > >> As for running with the API, I don't think you can up the priority as >> it is in the same process as blue. I may be able to try increasing the >> priority in Java, but I am not sure how much of a difference that will >> make. I just tried setting the render thread to max priority, but I >> don't know if it makes a difference. It still won't be like upping >> the priority of the process using sched. (The code is now in CVS and >> will be in the release build I do tonight.) > > I tried cvs, and it doesn't make any difference. > >> I'm not sure of any other thing I can do to increase the priority. On >> Linux, you might be able to increase the priority of the java process >> that runs blue as a whole, though I don't know how the system will >> react to that. > > I was able to make blue run glitch free with the API with -B256 -b45 () by > doing "sudo chrt -f -p 80 17783", where 17783 is the pid of the java > process. This is good news, as it means there must be a way to get things > running smoothly. However in itself it is not a viable solution since the > process that needs this seems to be spawn when rendering. This means I have > to start the render, look at the output of htop, and issue the command with > the correct pid. I attached a screenshot of htop after the changed priority. > So I think we need to make changes to the way blue spawns the thread, doing > something like this automatically. > > BTW: I see two java processes taking up cpu when rendering with blue, one > seems to be the main blue thread, since it keeps it's pid throughout a blue > session, the other one I suspect is the one spawned when rendering. I also > tried changing the pid of the main thread, but that doesn't seem to be > inherited by the render thread. There are also quite alot of other threads > looking similar (in the screenshot I count 9 in all), but taking up much > less cpu. Could you elaborate a bit on why all these threads are there? > > Where in the code is the spawning of the render thread happening? I'd like > to take a look at the code and fool around with it a bit, maybe I can come > up with something... > > -- > Atte > > http://atte.dk http://modlys.dk > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Bluemusic-users mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-users > > |
From: Steven Y. <ste...@gm...> - 2008-10-24 07:30:34
|
Okay, I thing we are in agreement here. If anyone else has an issue, please let me know, otherwise, I am going to go ahead with changing that behavior tomorrow before releasing (I was in the middle of building tonight but figured I can wait until this is resolved first tomorrow). Thanks! steven On Thu, Oct 23, 2008 at 11:30 PM, Atte André Jensen <att...@gm...> wrote: > Steven Yi wrote: > >> I actually have never come across this in my own code as I don't use >> i(kvar) for the things I need to do. I am not sure there is a >> csound-only solution; perhaps the best thing might be for me to remove >> generation as constant altogether when a widget is set as automatable, >> and use the constant generation only in the case when it is not >> automatable. This may change behavior for older projects though, but >> the workaround would be clear. > > I think that might be a good solution. Would there be a slight > performance overhead (due to automatable widgets being k-rate and not > i-rate), or? In any case it would be very, very small, and it makes > blues behavior more clear. > > Backwards compatibility is always a good thing, but if it's holding new > directions for the software back, it could be necessary to break it. > > -- > Atte > > http://atte.dk http://modlys.dk > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Bluemusic-users mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-users > |
From: Steven Y. <ste...@gm...> - 2008-10-24 14:51:39
|
Hi Atte, I've gotten glitches too and have not yet figured out why, though I am still looking at it. As for BSB's not working, I did try to have it so that on migration it would try to pick and choose correctly to set that automatable flag correctly. I'm afraid though that it might just be that a number of items in blueShare need updating. steven On Fri, Oct 24, 2008 at 2:23 AM, Atte André Jensen <att...@gm...> wrote: > Steven Yi wrote: >> Okay, I thing we are in agreement here. If anyone else has an issue, >> please let me know, > > Well, I (as I wrote in another mail) hacked up one of my projects to use > the API. I found it performed badly (with glitches) which might just be > my setup. Also, one could just keep using the non-API way with > appropriate changes to the instruments. > > More importantly I found that alot of the BSB's doesn't work with > widgets values being expanded as k-rate variables. A quick fix might be > to set them to non-automatable, but it's gonna take quite some work to > get everything in blueShare working again. > > -- > Atte > > http://atte.dk http://modlys.dk > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Bluemusic-users mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-users > |
From: Atte A. J. <att...@gm...> - 2008-10-24 16:40:25
|
Steven Yi wrote: > I've gotten glitches too and have not yet figured out why, though I am > still looking at it. So what you're saying is that using the API is not a 100% viable solution ATM, but that it has potential, and that we should strive for ironing out the bumps and glitches to make it work as well as "the old way"? No problem with me :-) I was more worried if I was the only one getting strange behavior. BTW: I got so fed up with strangeness under ubuntu today that I installed debian on a second partition. Some things are not working yet, but I will setup blue etc and report back on how things are performing there... -- Atte http://atte.dk http://modlys.dk |
From: Steven Y. <ste...@gm...> - 2008-10-28 23:02:47
|
Hi Atte, Glad that works! I'm going to update documentation will issue a release tonight. As for running with the API, I don't think you can up the priority as it is in the same process as blue. I may be able to try increasing the priority in Java, but I am not sure how much of a difference that will make. I just tried setting the render thread to max priority, but I don't know if it makes a difference. It still won't be like upping the priority of the process using sched. (The code is now in CVS and will be in the release build I do tonight.) I'm not sure of any other thing I can do to increase the priority. On Linux, you might be able to increase the priority of the java process that runs blue as a whole, though I don't know how the system will react to that. Thanks! steven On Tue, Oct 28, 2008 at 2:40 PM, Atte André Jensen <att...@gm...> wrote: > Steven Yi wrote: > >> Could you take a look (or update from CVS) and see if it works for you? > > That seems to work great, thanks. > > However now I'm no longer able to run without glitches even without the > API. I now have to use -b 512 and -B 1024, isn't that un-reasonably > large buffers? > > When looking at the output of htop, I don't see any process running with > priority 80 eventhough I have --sched=80 in my advanced options. I'm > wondering if running with the API means that csound inherits the > priority of blue? If possible it would be better to have only csound run > with high priority to make it imune to rendering in the gui. > > In any case I'd be most interrested in hearing others thoughts, > findings, experiences and knowledge on this, esp under linux. > > NB: It was extremely cool to move sliders in my instruments and hearing > the result in realtime. Working through the API is for sure the future > of blue. > > -- > Atte > > http://atte.dk http://modlys.dk > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Bluemusic-users mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-users > |
From: Michael B. <got...@ya...> - 2008-10-29 15:07:54
|
Perhaps someone could, once the release is out, post a message here detailing what we should do to fix our current blueShare stuff (sorry, I haven't been following this topic as closely as I should have). Thanks, Michael ----- Original Message ---- From: Atte André Jensen <att...@gm...> To: blue users mailing list <blu...@li...> Sent: Wednesday, October 29, 2008 3:06:37 AM Subject: Re: [Bluemusic-users] assigning widgets values to i-rate variables Steven Yi wrote: > Glad that works! I'm going to update documentation will issue a > release tonight. Great! This means that we can start working on new versions of stuff in blueShare. Should I start making notes about which things work, and which doesn't? I'm not sure that all authors of the affected stuff in blueShare are active, should we (I) hotfix their code and submit API versions of the instruments/fx in question? > As for running with the API, I don't think you can up the priority as > it is in the same process as blue. I may be able to try increasing the > priority in Java, but I am not sure how much of a difference that will > make. I just tried setting the render thread to max priority, but I > don't know if it makes a difference. It still won't be like upping > the priority of the process using sched. (The code is now in CVS and > will be in the release build I do tonight.) I tried cvs, and it doesn't make any difference. > I'm not sure of any other thing I can do to increase the priority. On > Linux, you might be able to increase the priority of the java process > that runs blue as a whole, though I don't know how the system will > react to that. I was able to make blue run glitch free with the API with -B256 -b45 () by doing "sudo chrt -f -p 80 17783", where 17783 is the pid of the java process. This is good news, as it means there must be a way to get things running smoothly. However in itself it is not a viable solution since the process that needs this seems to be spawn when rendering. This means I have to start the render, look at the output of htop, and issue the command with the correct pid. I attached a screenshot of htop after the changed priority. So I think we need to make changes to the way blue spawns the thread, doing something like this automatically. BTW: I see two java processes taking up cpu when rendering with blue, one seems to be the main blue thread, since it keeps it's pid throughout a blue session, the other one I suspect is the one spawned when rendering. I also tried changing the pid of the main thread, but that doesn't seem to be inherited by the render thread. There are also quite alot of other threads looking similar (in the screenshot I count 9 in all), but taking up much less cpu. Could you elaborate a bit on why all these threads are there? Where in the code is the spawning of the render thread happening? I'd like to take a look at the code and fool around with it a bit, maybe I can come up with something... -- Atte http://atte.dk http://modlys.dk |
From: Steven Y. <ste...@gm...> - 2008-10-30 05:26:18
|
Hi Michael, I added some info to the manual and in the change log about it: http://www.csounds.com/stevenyi/blue/usermanual/html/apb.html so basically, if you get an error, you'll either have to change the widget to not allow automation or change code to work with a k-rate signal. Thanks! steven On Wed, Oct 29, 2008 at 8:07 AM, Michael Bechard <got...@ya...> wrote: > Perhaps someone could, once the release is out, post a message here detailing what we should do to fix our current blueShare stuff (sorry, I haven't been following this topic as closely as I should have). > > Thanks, > Michael > > > > ----- Original Message ---- > From: Atte André Jensen <att...@gm...> > To: blue users mailing list <blu...@li...> > Sent: Wednesday, October 29, 2008 3:06:37 AM > Subject: Re: [Bluemusic-users] assigning widgets values to i-rate variables > > Steven Yi wrote: > >> Glad that works! I'm going to update documentation will issue a >> release tonight. > > Great! This means that we can start working on new versions of stuff in blueShare. Should I start making notes about which things work, and which doesn't? > > I'm not sure that all authors of the affected stuff in blueShare are active, should we (I) hotfix their code and submit API versions of the instruments/fx in question? > >> As for running with the API, I don't think you can up the priority as >> it is in the same process as blue. I may be able to try increasing the >> priority in Java, but I am not sure how much of a difference that will >> make. I just tried setting the render thread to max priority, but I >> don't know if it makes a difference. It still won't be like upping >> the priority of the process using sched. (The code is now in CVS and >> will be in the release build I do tonight.) > > I tried cvs, and it doesn't make any difference. > >> I'm not sure of any other thing I can do to increase the priority. On >> Linux, you might be able to increase the priority of the java process >> that runs blue as a whole, though I don't know how the system will >> react to that. > > I was able to make blue run glitch free with the API with -B256 -b45 () by doing "sudo chrt -f -p 80 17783", where 17783 is the pid of the java process. This is good news, as it means there must be a way to get things running smoothly. However in itself it is not a viable solution since the process that needs this seems to be spawn when rendering. This means I have to start the render, look at the output of htop, and issue the command with the correct pid. I attached a screenshot of htop after the changed priority. So I think we need to make changes to the way blue spawns the thread, doing something like this automatically. > > BTW: I see two java processes taking up cpu when rendering with blue, one seems to be the main blue thread, since it keeps it's pid throughout a blue session, the other one I suspect is the one spawned when rendering. I also tried changing the pid of the main thread, but that doesn't seem to be inherited by the render thread. There are also quite alot of other threads looking similar (in the screenshot I count 9 in all), but taking up much less cpu. Could you elaborate a bit on why all these threads are there? > > Where in the code is the spawning of the render thread happening? I'd like to take a look at the code and fool around with it a bit, maybe I can come up with something... > > -- Atte > > http://atte.dk http://modlys.dk > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Bluemusic-users mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-users > |