bluemusic-devel Mailing List for blue (Page 5)
Brought to you by:
kunstmusik
You can subscribe to this list here.
2004 |
Jan
(3) |
Feb
(3) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
(14) |
Mar
(7) |
Apr
(13) |
May
|
Jun
(7) |
Jul
(47) |
Aug
(11) |
Sep
(7) |
Oct
(3) |
Nov
(3) |
Dec
|
2006 |
Jan
(1) |
Feb
(28) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
(11) |
Feb
(14) |
Mar
|
Apr
(6) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
2009 |
Jan
(6) |
Feb
|
Mar
|
Apr
(16) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(2) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
From: Steven Y. <ste...@gm...> - 2006-03-13 04:31:04
|
Hi Andres, I tried this file and did not notice any timeline instability. Could you describe the instability in more detail? I'm not sure this is related, but for the timeline it auto updates the size to add time if you're dragging and you go beyond a certain time limit, but I think it's after 5:00 and then every minute after that. It would have also happened with snap or without. Could you also mention what version of blue, what operating system and version, and also what version of Java you are running? Thanks, steven On 3/12/06, Andres Cabrera <an...@ge...> wrote: > Hi Steven, > I've noticed a strange behaviour of the time display within polyobjects > which seems related to the snap options and panel. I've attached a file, > and please try the following: > -Open the soundobject library and enter the sound object. There, go to > the last object and drag it. Notice how the timeline is not stable. It > can be solved by opening the snap panel, disabling snap and closing the > panel again. > > Cheers, > Andr=E9s > > > > |
From: Andres C. <an...@ge...> - 2006-03-12 14:49:35
|
Hi Steven, I've noticed a strange behaviour of the time display within polyobjects which seems related to the snap options and panel. I've attached a file, and please try the following: -Open the soundobject library and enter the sound object. There, go to the last object and drag it. Notice how the timeline is not stable. It can be solved by opening the snap panel, disabling snap and closing the panel again. Cheers, Andr=C3=A9s |
From: Steven Y. <ste...@gm...> - 2006-03-09 07:05:47
|
Hi All, I'm thinking blueShare (the serverside php part) needs a real rewrite. I'm having a hard time working with the existing code as it wasn't my original design and some parts seem like overkill. I am thinking that: -classes need to be redone to remove any presentation information to separate model and view (to_string and to_xml would be useful and clean though I think) -i'm not fond of the presentation classes and functions; I'd like to move to Smarty Templates and simple CSS for styling it's not a big rewrite I am thinking as it's not that big a project after all. I am going ahead with the current design until the Effects part of blueShare is done, but soon after will likely start a new CVS branch from the current module that will do work in and eventually remerge back in when the change is complete. I am thinking: -needs to work with register_globals =3D off -no globals -php 4+ -Smarty Any thoughts? steven |
From: Michael B. <got...@ya...> - 2006-02-28 14:40:48
|
--- Steven Yi <ste...@gm...> wrote: > ... > I was beginning to think also that UDO's would have > something like: > > opcode echo > > ain1, ain2, [list of values set from interface] xin > > ...code... > > xout aout1, aout2 > endop > > So that we can reuse UDO's and send in parameters > from the interface, > but I think it could be a headache and that there > won't be *THAT* many > effects, and even if there were many, it wouldn't > affect parsing too > much. > I'm not quite sure I follow. One can resuse instruments, too, and send in interface parameters to them via instrument params (p3, p4, etc.), so what's the advantage (aside from the ability to set ksmps separately)? And I wouldn't be too sure about people not having too many effects. I like effects and plan to use them liberally, if and when I get back into csound. > I am thinking that all effects though will be given > autoassigned names > with the original name added as a comment to the > output, something > like: > > opcode bMixerEffect0 ; mixer effect: echo > ... > endop > > this is to avoid collision of effects names, and may > play a part later > if we arm parameters for automation. > Sounds smart. Michael Bechard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Steven Y. <ste...@gm...> - 2006-02-28 05:52:41
|
Hi day5, I think the example you posted is in line with what I was going to avoid for simplicity's sake of having control parameters be inputs into the UDO. I am planning on making it be values internally set within the body of the code in the same way BSB is, as there are issues invovled with name space clashing and versioning of effects. Otherwise, what you have posted will certainly be possible to express within the new effects system (minus the control signal automation, at least in the initial version). steven On 2/27/06, day 5 <da...@gm...> wrote: > real time equalizer > > <CsoundSynthesizer> > <CsInstruments> > > > sr =3D 44100 > kr =3D 441 > ksmps =3D 100 > nchnls =3D 2 > zakinit 2, 2 > ctrlinit 1, 8, 40, 9, 40, 10, 40, 11, 16, 12, 40, 13, 40, = 14, 40, 15, > 16 > > #define SOUNDFILE # "/Volumes/Neuromancer/dc1/dc1-5.aif" # > > /*=3D=3D=3D =3D=3D=3D*/ > > opcode scale, k, kkk > > kval, kmin, kmax xin > > kscl =3D kval * (kmax - kmin) + kmin > > xout kscl > > endop > > /*=3D=3D=3D =3D=3D=3D*/ > ; klvl =3D 1, flat > ; klvl =3D 4, +12dB > ; klvl =3D 0.1, -20dB > > opcode equalizer, aaa, akkkkkk > > ain, klvl1, klvl2, klvl3, kq1, kq2, kq3 xin > > alo rbjeq ain, 100, klvl1, kq1, 1, 10 > amd rbjeq ain, 800, klvl2, kq2, 1, 8 > ahi rbjeq ain, 8000, klvl3, kq3, 1, 12 > > xout alo, amd, ahi > > endop > > /*=3D=3D=3D =3D=3D=3D*/ > > opcode denormk, k, k > > ken xin > > ain upsamp ken > denorm ain > kout downsamp ain > > xout kout > > endop > > ;//-- > /*--- > > instr 1 > > ar0 phasor 1/(sr/ftlen(1)) > ar0 =3D (ar0 * ftlen(1)) > > atbl table ar0, 1 > atbr table (ftlen(1)-ar0), 1 > > atbl =3D atbl * 22200 > atbr =3D atbr * 22200 > > zaw atbl, 1 > zaw atbr, 2 > > endin > > ---*/ > > instr 1 > > al, ar diskin2 $SOUNDFILE, 1, 0, 1 > > zaw al, 1 > zaw ar, 2 > > endin > > /*--- ---*/ > > instr 2 ; klvl in range 0.025-3 > ; for -26 to +9 dB range > > klv1 ctrl7 1, 8, 0, 1 > klv2 ctrl7 1, 9, 0, 1 > klv3 ctrl7 1, 10, 0, 1 > kqu1 ctrl7 1, 12, 0, 1 > kqu2 ctrl7 1, 13, 0, 1 > kqu3 ctrl7 1, 14, 0, 1 > > ktl ctrl7 1, 11, 0, 1 > ktq ctrl7 1, 15, 0, 1 > > ktl scale ktl, 0.01, 0.618 > klv1 portk klv1, ktl > klv2 portk klv2, ktl > klv3 portk klv3, ktl > > ktq scale ktq, 0.01, 0.618 > kqu1 portk kqu1, ktq > kqu2 portk kqu2, ktq > kqu3 portk kqu3, ktq > > klvl1 scale klv1, 0.001, 8 > klvl2 scale klv2, 0.001, 8 > klvl3 scale klv3, 0.001, 8 > kq1 scale kqu1, 0.1, 3 > kq2 scale kqu2, 0.1, 3 > kq3 scale kqu3, 0.1, 3 > > atbl zar 1 > atbr zar 2 > > all, aml, ahl equalizer atbl, klvl1, klvl2, klvl3, kq1, kq2, kq3 > alr, amr, ahr equalizer atbr, klvl1, klvl2, klvl3, kq1, kq2, kq3 > > amixl =3D (all+aml+ahl)/3 > amixr =3D (alr+amr+ahr)/3 > > outs amixl, amixr > zacl 1, 2 > > endin > > /*--- ---*/ > > instr 3 ; listen to the zak bus > > al zar 1 > ar zar 2 > > outs al, ar > zacl 1, 2 > > endin > > /*--- ---*/ > </CsInstruments> > <CsScore> > > i1 0 3600 > i2 0 3600 > ;i3 0 3600 > > e > </CsScore> > > </CsoundSynthesizer> > > > ./d5 > > On Feb 27, 2006, at 6:17 PM, Steven Yi wrote: > > > Hi All, > > > > I'm posting this on the dev list as it's more implementation oriented. > > I am thinking that effects should generate as UDO's, and for the > > editor you choose number of inputs and outputs (1 or more for each), > > and those values are going to come in hardcoded ain1, ain2, etc. and > > output as aout1, aout2, depending on num inputs/outputs set. For > > coding an effect, you only have to implement the code and not worry > > about the UDO details. > > > > I was beginning to think also that UDO's would have something like: > > > > opcode echo > > > > ain1, ain2, [list of values set from interface] xin > > > > ...code... > > > > xout aout1, aout2 > > endop > > > > So that we can reuse UDO's and send in parameters from the interface, > > but I think it could be a headache and that there won't be *THAT* many > > effects, and even if there were many, it wouldn't affect parsing too > > much. > > > > I am thinking that all effects though will be given autoassigned names > > with the original name added as a comment to the output, something > > like: > > > > opcode bMixerEffect0 ; mixer effect: echo > > ... > > endop > > > > this is to avoid collision of effects names, and may play a part later > > if we arm parameters for automation. > > > > Just thought I'd throw this out there to see if this sounds good or > > not. I'm going to go ahead with this design when I start working > > later tonight and can change later if other solutions or issues are > > presented. > > > > Thanks! > > steven > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Bluemusic-devel mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-devel > |
From: day 5 <da...@gm...> - 2006-02-28 02:37:15
|
real time equalizer <CsoundSynthesizer> <CsInstruments> sr = 44100 kr = 441 ksmps = 100 nchnls = 2 zakinit 2, 2 ctrlinit 1, 8, 40, 9, 40, 10, 40, 11, 16, 12, 40, 13, 40, 14, 40, 15, 16 #define SOUNDFILE # "/Volumes/Neuromancer/dc1/dc1-5.aif" # /*=== ===*/ opcode scale, k, kkk kval, kmin, kmax xin kscl = kval * (kmax - kmin) + kmin xout kscl endop /*=== ===*/ ; klvl = 1, flat ; klvl = 4, +12dB ; klvl = 0.1, -20dB opcode equalizer, aaa, akkkkkk ain, klvl1, klvl2, klvl3, kq1, kq2, kq3 xin alo rbjeq ain, 100, klvl1, kq1, 1, 10 amd rbjeq ain, 800, klvl2, kq2, 1, 8 ahi rbjeq ain, 8000, klvl3, kq3, 1, 12 xout alo, amd, ahi endop /*=== ===*/ opcode denormk, k, k ken xin ain upsamp ken denorm ain kout downsamp ain xout kout endop ;//-- /*--- instr 1 ar0 phasor 1/(sr/ftlen(1)) ar0 = (ar0 * ftlen(1)) atbl table ar0, 1 atbr table (ftlen(1)-ar0), 1 atbl = atbl * 22200 atbr = atbr * 22200 zaw atbl, 1 zaw atbr, 2 endin ---*/ instr 1 al, ar diskin2 $SOUNDFILE, 1, 0, 1 zaw al, 1 zaw ar, 2 endin /*--- ---*/ instr 2 ; klvl in range 0.025-3 ; for -26 to +9 dB range klv1 ctrl7 1, 8, 0, 1 klv2 ctrl7 1, 9, 0, 1 klv3 ctrl7 1, 10, 0, 1 kqu1 ctrl7 1, 12, 0, 1 kqu2 ctrl7 1, 13, 0, 1 kqu3 ctrl7 1, 14, 0, 1 ktl ctrl7 1, 11, 0, 1 ktq ctrl7 1, 15, 0, 1 ktl scale ktl, 0.01, 0.618 klv1 portk klv1, ktl klv2 portk klv2, ktl klv3 portk klv3, ktl ktq scale ktq, 0.01, 0.618 kqu1 portk kqu1, ktq kqu2 portk kqu2, ktq kqu3 portk kqu3, ktq klvl1 scale klv1, 0.001, 8 klvl2 scale klv2, 0.001, 8 klvl3 scale klv3, 0.001, 8 kq1 scale kqu1, 0.1, 3 kq2 scale kqu2, 0.1, 3 kq3 scale kqu3, 0.1, 3 atbl zar 1 atbr zar 2 all, aml, ahl equalizer atbl, klvl1, klvl2, klvl3, kq1, kq2, kq3 alr, amr, ahr equalizer atbr, klvl1, klvl2, klvl3, kq1, kq2, kq3 amixl = (all+aml+ahl)/3 amixr = (alr+amr+ahr)/3 outs amixl, amixr zacl 1, 2 endin /*--- ---*/ instr 3 ; listen to the zak bus al zar 1 ar zar 2 outs al, ar zacl 1, 2 endin /*--- ---*/ </CsInstruments> <CsScore> i1 0 3600 i2 0 3600 ;i3 0 3600 e </CsScore> </CsoundSynthesizer> ./d5 On Feb 27, 2006, at 6:17 PM, Steven Yi wrote: > Hi All, > > I'm posting this on the dev list as it's more implementation oriented. > I am thinking that effects should generate as UDO's, and for the > editor you choose number of inputs and outputs (1 or more for each), > and those values are going to come in hardcoded ain1, ain2, etc. and > output as aout1, aout2, depending on num inputs/outputs set. For > coding an effect, you only have to implement the code and not worry > about the UDO details. > > I was beginning to think also that UDO's would have something like: > > opcode echo > > ain1, ain2, [list of values set from interface] xin > > ...code... > > xout aout1, aout2 > endop > > So that we can reuse UDO's and send in parameters from the interface, > but I think it could be a headache and that there won't be *THAT* many > effects, and even if there were many, it wouldn't affect parsing too > much. > > I am thinking that all effects though will be given autoassigned names > with the original name added as a comment to the output, something > like: > > opcode bMixerEffect0 ; mixer effect: echo > ... > endop > > this is to avoid collision of effects names, and may play a part later > if we arm parameters for automation. > > Just thought I'd throw this out there to see if this sounds good or > not. I'm going to go ahead with this design when I start working > later tonight and can change later if other solutions or issues are > presented. > > Thanks! > steven |
From: Steven Y. <ste...@gm...> - 2006-02-27 23:17:45
|
Hi All, I'm posting this on the dev list as it's more implementation oriented. I am thinking that effects should generate as UDO's, and for the editor you choose number of inputs and outputs (1 or more for each), and those values are going to come in hardcoded ain1, ain2, etc. and output as aout1, aout2, depending on num inputs/outputs set. For coding an effect, you only have to implement the code and not worry about the UDO details. I was beginning to think also that UDO's would have something like: opcode echo ain1, ain2, [list of values set from interface] xin ...code... xout aout1, aout2 endop So that we can reuse UDO's and send in parameters from the interface, but I think it could be a headache and that there won't be *THAT* many effects, and even if there were many, it wouldn't affect parsing too much. I am thinking that all effects though will be given autoassigned names with the original name added as a comment to the output, something like: opcode bMixerEffect0 ; mixer effect: echo ... endop this is to avoid collision of effects names, and may play a part later if we arm parameters for automation. Just thought I'd throw this out there to see if this sounds good or not. I'm going to go ahead with this design when I start working later tonight and can change later if other solutions or issues are presented. Thanks! steven |
From: Steven Y. <ste...@gm...> - 2006-02-22 23:42:06
|
Hi Ugur, Thanks for taking a look at the code! I think I'll go ahead and move them up to the main package then. I think the rest won't be so bad; I have some ideas for the Unit Editor dialog already. I am planning to make another release fairly soon though as I just redid the SoundFont viewer and am about to add functionality to the PianoRoll to have a mode to output MIDI note values, so will start again on the FlowGraph after the release (which I hope to get out in the next day or two). Hope you had a good holiday and looking forward to coding again with you on the FlowGraph! steven On 2/22/06, sokratesla <ugu...@gm...> wrote: > # I've looked to the CVS repositories and the classes in the > .flowGraph.test package looks great. Particularly the > generateInstrument() method and the VariableManager class. (and they > seems complicated because I didn't dealed with the program for a > while) It gives hope to see some Csound code at least. :-) > # So, the main problem is now solved, the remaining part is designing > the graphical UI, Unit Editor and different types of units. > > # I was taking holiday and struggled with the registration period for > the new semester. Next week I'll be able to return to code. > # Thank you! > -ugur- > > On 2/22/06, Steven Yi <ste...@gm...> wrote: > > Hi Ugur and All, > > > > In the blue.orchestra.flowGrapht.test package I've completed an > > initial version of the code that compiles from GraphUnit's to Csound > > code. I think this is design is moving in the right direction, but of > > course would like any other opinions on the matter. The TestFlowGraph > > class is a bit dense but on the other hand, a user would never do this > > stuff by hand. Most of the work for definining Units will already > > have been done by the time they get to the FlowGraph editor (via an > > included library of units), and it will be mostly just connecting > > objects up. > > > > I think we should also follow Ugur's suggestion in having an interface > > that the user-defined Units, the Constant objects, as well as others > > should derive from. Because GraphUnit will hold the connection and > > visual details, the interface for what Unit will derive from should > > have a getEditor() method that returns either a JComponent editor. > > For simple user-defined units, the getEditor() method will return just > > a JLabel which will not be editable and that can go in the Box that is > > shown on the editor. For the Constant object, it can return a number > > box or a string entry editor depending on type of Constant. > > > > I think the design so far is good but of course not perfect; I'd like > > to continue on with this design and move these classes up into the > > normal package and remove the test package, with these classes to > > become the new FlowGraph core classes. I'll wait to hear on comments > > before doing so; if it's good for everyone else, then I will make the > > complete modifications to the editor classes to work with the new code > > (or at least compile) before making the big switch. > > > > Thanks! > > steven > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642 > > _______________________________________________ > > Bluemusic-devel mailing list > > Blu...@li... > > https://lists.sourceforge.net/lists/listinfo/bluemusic-devel > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Bluemusic-devel mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-devel > |
From: sokratesla <ugu...@gm...> - 2006-02-22 22:29:11
|
# I've looked to the CVS repositories and the classes in the .flowGraph.test package looks great. Particularly the generateInstrument() method and the VariableManager class. (and they seems complicated because I didn't dealed with the program for a while) It gives hope to see some Csound code at least. :-) # So, the main problem is now solved, the remaining part is designing the graphical UI, Unit Editor and different types of units. # I was taking holiday and struggled with the registration period for the new semester. Next week I'll be able to return to code. # Thank you! -ugur- On 2/22/06, Steven Yi <ste...@gm...> wrote: > Hi Ugur and All, > > In the blue.orchestra.flowGrapht.test package I've completed an > initial version of the code that compiles from GraphUnit's to Csound > code. I think this is design is moving in the right direction, but of > course would like any other opinions on the matter. The TestFlowGraph > class is a bit dense but on the other hand, a user would never do this > stuff by hand. Most of the work for definining Units will already > have been done by the time they get to the FlowGraph editor (via an > included library of units), and it will be mostly just connecting > objects up. > > I think we should also follow Ugur's suggestion in having an interface > that the user-defined Units, the Constant objects, as well as others > should derive from. Because GraphUnit will hold the connection and > visual details, the interface for what Unit will derive from should > have a getEditor() method that returns either a JComponent editor. > For simple user-defined units, the getEditor() method will return just > a JLabel which will not be editable and that can go in the Box that is > shown on the editor. For the Constant object, it can return a number > box or a string entry editor depending on type of Constant. > > I think the design so far is good but of course not perfect; I'd like > to continue on with this design and move these classes up into the > normal package and remove the test package, with these classes to > become the new FlowGraph core classes. I'll wait to hear on comments > before doing so; if it's good for everyone else, then I will make the > complete modifications to the editor classes to work with the new code > (or at least compile) before making the big switch. > > Thanks! > steven > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642 > _______________________________________________ > Bluemusic-devel mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-devel > |
From: Steven Y. <ste...@gm...> - 2006-02-22 04:04:14
|
Hi Ugur and All, In the blue.orchestra.flowGrapht.test package I've completed an initial version of the code that compiles from GraphUnit's to Csound code. I think this is design is moving in the right direction, but of course would like any other opinions on the matter. The TestFlowGraph class is a bit dense but on the other hand, a user would never do this stuff by hand. Most of the work for definining Units will already have been done by the time they get to the FlowGraph editor (via an included library of units), and it will be mostly just connecting objects up. I think we should also follow Ugur's suggestion in having an interface that the user-defined Units, the Constant objects, as well as others should derive from. Because GraphUnit will hold the connection and visual details, the interface for what Unit will derive from should have a getEditor() method that returns either a JComponent editor.=20 For simple user-defined units, the getEditor() method will return just a JLabel which will not be editable and that can go in the Box that is shown on the editor. For the Constant object, it can return a number box or a string entry editor depending on type of Constant. I think the design so far is good but of course not perfect; I'd like to continue on with this design and move these classes up into the normal package and remove the test package, with these classes to become the new FlowGraph core classes. I'll wait to hear on comments before doing so; if it's good for everyone else, then I will make the complete modifications to the editor classes to work with the new code (or at least compile) before making the big switch. Thanks! steven |
From: Steven Yi <ste...@gm...> - 2006-02-11 04:16:46
|
Hi Ugur and all, I've been working on the FlowGraph sketch, basing it now on your work and also from my old MacroPatch program. It seems to me that the Cable class should have not ports to connect to, but rather what GraphUnit is on the screen and then the port number, and within the port a connection number (the last one for the case of mutli-connection input ports). More work is done in the Graphical Editor part then with this, but on the other hand, compilation is not so bad, and the code in MacroPatch, while rather simlistic, works. I still have to continue looking at the problem, but thought I'd mention this. I will write a test sometime this weekend that will show compilation. Thanks! steven |
From: Steven Yi <ste...@gm...> - 2006-02-09 08:28:58
|
Hi Ugur, I worked on a set of ideas and classes and committed them in the blue.orchestra.flowgraph.test package. I am running into some issues that I think are already solved by you and also in Cabel, and also apparently by myself 5 years ago too! (I found my old macro patch program and put it on http://www.kunstmusik.com/macroPatch.zip if you are interested to see it; the code is ugly and old, but works!). I also played with Cabel today and was once again impressed with it.=20 I think the Port class is important to have some meta data attached to it, which cabel does, and that includes minimum value, maximum value, default value, and description. In Cabel, all ports start off with their defaults; you can edit the value for the port by double clicking the box and then a group of sliders show up for editing the value of the port. If you connect something to that port, that property become non-editable and the default isn't used. I think this is a very good thing to implement. We also need to have as part of the Unit Editor the ability to explicitly designate Input Ports and output Ports. For those, I am thinking of two table editors, so you can add and edit their type and properties. Also, I think tonight that it is import to include a port that can accept multiple-inputs. It would automatically add an extra visual port beyond the number already connected, and if you add a connection an extra visual port is added. The values from the port then should generate a comma separated list to be used in the code. The reason for this is to have something like a generic sum Unit, where you can add as many cables and the code would compile out to: aout sum a1,a2,a3,a4,a5,a6 This kind of variable arg list I think will be handy, but will require a mapping function from visual ports to actual ports. Without this support though, we'll end up having something like Music V's AD2, AD3, AD4 unit generates for any opcode that can take a variable number of inputs, which I think would be painful. I'm going to look at the MacroPatch code myself and continue to study cabel and the code you have. I think we should proceed by hammering out the Model classes and creating test cases that use the model classes directly; if we know that works, then coding the User Interface won't be difficult afterwards. steven p.s. - Another nice thing about Cabel's design decision to wrap everything in UDO's is that there is no worry of namespace clashes of variable names as they are all encapsulated. I think we can work around it though with a Unique ID system. On 2/8/06, Steven Yi <ste...@gm...> wrote: > Hi Ugur, > > Just a quick reply right now to be followed with a longer reply: I > implemented a system in the never-finished CeciliaModule that parsed > all global variables and reassigned new unique variable names. This > type of thing might be easier than parsing into separate opcodes, > simply looking for variables (i.e. code that starts with i-, k-, a-, > S-, w-, and f-) and if found, register it with a VariablesManager > class to get a unique variable name, and then text replace within the > unit. I still don't think an Opcode class is necessary, and my hunch > is that we also won't have to parse down to the Opcode level and > recreate the whole graph instrument graph at that atomic a level. > What we will need to parse the graph of the objects at the Unit level, > and in generating the code, making sure all variables are unique, so > that if you use 5 copies of the same unit, they don't interfere with > each other. > > (Which reminds me, I wrote a patch system some 4 or 5 years ago that > did work, but was very simplistic. I'll try digging out that code to > see if there is anything there to reuse.) > > Juast as a note: I am getting close to hooking up the basic Mixer > system (no effects or sends; probably tonight) and after some testing > of that, will look to put out a release and then will refocus to split > time between the Effects Editor and hooking that into the Mixer, and > then also will be spending much more time with the FlowGraph. > > I'll try to reply more later when I have more time(probably later tonight= )! > steven > > On 2/8/06, sokratesla <ugu...@gm...> wrote: > > # I'm thinking about the final algorithm which generates the Csound > > code. If we determine it, it gets easier to set our classes. > > # The algorithm consists of two main parts: First "naming the Ports". > > Namely, all Ports have similar names "asig", "aout", "kenv", "ival" > > etc. First part will change them "a1", "a2", "a3", "k57" etc. (or if > > we want to struggle more, asig1, asig2, aout1, aout2...) > > # FlowGraph is responsible for the implementaion of this algorithm. > > # It'll use a recursive function for this purpose. > > # All Units are in an ArrayList in the FlowGraph. It starts to control > > from to first Unit wheter it is "checked". (checked means all of the > > Ports of this Unit is "named") If it isn't checked, the function looks > > to all output Ports that are connected to this Units input Ports. If > > all of them are named, it'll name the input Ports and check the Unit. > > # But if some of the output Ports that are connected to this Units > > input Ports are not named, the function will be applied to the owner > > Units of that output Ports. (here is the recursion, if I'm using the > > term correctly) So, the function go upwards through the Units until it > > finds a Unit of which input Ports are named, or which has no input > > Ports. > > # After all recursive functions are finished, FlowGraph turns to the > > first Unit in the ArrayList again and controls all of them whether > > they are checked. If it come across an unchecked Unit applies that > > recursive function on it and return to the first Unit. First part > > stops when the counter reaches to the end of Unit ArrayList. > > # So, all Ports are named with proper names. The remaining job is > > constructing the code from the contents of units in proper order. > > # I think, cutting the code into parts by using Port and Opcode > > classes will help at this part. > > # "Naming part" will change the names of the Ports. I suppose, it gets > > harder when a Unit have its piece of code as a String. If there are > > more than one row, namely more opcodes, in its code some of which have > > same input argument names, renaming them will be harder. Which input > > Port is related with which argument? This is the difficulty that I > > faced one day before submitting my Java project :-) Units had have > > only code Strings (no Ports, no Opcodes) and after every editing they > > have to constructing their IO's again. But then I realized that when I > > give the possibility of having more than one opcodes it isn't possible > > to reconstruct the code with appropriate variable names. > > # For the second part goes in reverse direction of the first part. > > (from above to downwards) It searches for a Unit which have no inputs, > > or constant inputs, or p-field initializations, and starts from that > > Unit. Write its code first, and check it. (now, checking means that, > > "its code is written, don't bother with it again") Then searchs for > > most above, unchecked Unit, and writes down its code... Until all > > Units are checked. > > # If we know explicitly which Opcode have which Ports, the > > reconstruction of the code will be extremely easy. > > > > # I didn't have thought about sub-patches. But they are standarts in > > every Flow Chart music software. We have to implement them :-) > > > > -ugur- > > > > On 2/8/06, Steven Yi <ste...@gm...> wrote: > > > HI Ugur, > > > > > > It still seems to me that it is unecessary, but it might be how I am > > > understanding the idea and what you have in mind may be different. To > > > me, the Unit class should be text Csound code whose inputs and output= s > > > are read either from the code or explicitly set using an editor. > > > There doesn't seem to be a requirement for a sub-object for opcodes i= n > > > this. When the patch is compiled, it shouldn't need to know the > > > contents of the Unit, only how to take the inputs and outputs and hoo= k > > > them up, so no need to know anything about the opcodes used in it. If > > > anything, I think the FlowGraph class could have sub-FlowGraph's, in > > > the same way a PD patch can be standalone or be a subpatch to another > > > patch. > > > > > > Am I misunderstanding what you have in mind? > > > > > > steven > > > > > > On 2/7/06, sokratesla <ugu...@gm...> wrote: > > > > On 2/7/06, Steven Yi <ste...@gm...> wrote: > > > > > Hi Ugur and all, > > > > > > > > > > I'm checking out the code that's going into CVS but am still conf= used > > > > > about the need for an Opcode class. I think the Unit class shoul= d be > > > > > enough to handle the abstraction of a single opcode or group of > > > > > orchestra code. > > > > > steven > > > > > > > > # Instead of having an array for opcode names, and an array of Port= s > > > > in the Unit, and finding out a way to link the opcodes with the > > > > related opcode, I think, having an Opcode class which knows its out= put > > > > and inputs ports and having a Unit which have an array of Opcodes i= s > > > > easier to implement? Its very unnecessary when the Unit have only o= ne > > > > opcode but I thought that makes the life easier when there are more > > > > than one opcodes, which may use the same Port etc. > > > > # I surmised that it makes the structure more clear. Do you think t= hat > > > > this classification unnecessary? > > > > -ugur- > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642 > > _______________________________________________ > > Bluemusic-devel mailing list > > Blu...@li... > > https://lists.sourceforge.net/lists/listinfo/bluemusic-devel > > > |
From: Steven Yi <ste...@gm...> - 2006-02-08 21:47:41
|
Hi Ugur, Just a quick reply right now to be followed with a longer reply: I implemented a system in the never-finished CeciliaModule that parsed all global variables and reassigned new unique variable names. This type of thing might be easier than parsing into separate opcodes, simply looking for variables (i.e. code that starts with i-, k-, a-, S-, w-, and f-) and if found, register it with a VariablesManager class to get a unique variable name, and then text replace within the unit. I still don't think an Opcode class is necessary, and my hunch is that we also won't have to parse down to the Opcode level and recreate the whole graph instrument graph at that atomic a level.=20 What we will need to parse the graph of the objects at the Unit level, and in generating the code, making sure all variables are unique, so that if you use 5 copies of the same unit, they don't interfere with each other. (Which reminds me, I wrote a patch system some 4 or 5 years ago that did work, but was very simplistic. I'll try digging out that code to see if there is anything there to reuse.) Juast as a note: I am getting close to hooking up the basic Mixer system (no effects or sends; probably tonight) and after some testing of that, will look to put out a release and then will refocus to split time between the Effects Editor and hooking that into the Mixer, and then also will be spending much more time with the FlowGraph. I'll try to reply more later when I have more time(probably later tonight)! steven On 2/8/06, sokratesla <ugu...@gm...> wrote: > # I'm thinking about the final algorithm which generates the Csound > code. If we determine it, it gets easier to set our classes. > # The algorithm consists of two main parts: First "naming the Ports". > Namely, all Ports have similar names "asig", "aout", "kenv", "ival" > etc. First part will change them "a1", "a2", "a3", "k57" etc. (or if > we want to struggle more, asig1, asig2, aout1, aout2...) > # FlowGraph is responsible for the implementaion of this algorithm. > # It'll use a recursive function for this purpose. > # All Units are in an ArrayList in the FlowGraph. It starts to control > from to first Unit wheter it is "checked". (checked means all of the > Ports of this Unit is "named") If it isn't checked, the function looks > to all output Ports that are connected to this Units input Ports. If > all of them are named, it'll name the input Ports and check the Unit. > # But if some of the output Ports that are connected to this Units > input Ports are not named, the function will be applied to the owner > Units of that output Ports. (here is the recursion, if I'm using the > term correctly) So, the function go upwards through the Units until it > finds a Unit of which input Ports are named, or which has no input > Ports. > # After all recursive functions are finished, FlowGraph turns to the > first Unit in the ArrayList again and controls all of them whether > they are checked. If it come across an unchecked Unit applies that > recursive function on it and return to the first Unit. First part > stops when the counter reaches to the end of Unit ArrayList. > # So, all Ports are named with proper names. The remaining job is > constructing the code from the contents of units in proper order. > # I think, cutting the code into parts by using Port and Opcode > classes will help at this part. > # "Naming part" will change the names of the Ports. I suppose, it gets > harder when a Unit have its piece of code as a String. If there are > more than one row, namely more opcodes, in its code some of which have > same input argument names, renaming them will be harder. Which input > Port is related with which argument? This is the difficulty that I > faced one day before submitting my Java project :-) Units had have > only code Strings (no Ports, no Opcodes) and after every editing they > have to constructing their IO's again. But then I realized that when I > give the possibility of having more than one opcodes it isn't possible > to reconstruct the code with appropriate variable names. > # For the second part goes in reverse direction of the first part. > (from above to downwards) It searches for a Unit which have no inputs, > or constant inputs, or p-field initializations, and starts from that > Unit. Write its code first, and check it. (now, checking means that, > "its code is written, don't bother with it again") Then searchs for > most above, unchecked Unit, and writes down its code... Until all > Units are checked. > # If we know explicitly which Opcode have which Ports, the > reconstruction of the code will be extremely easy. > > # I didn't have thought about sub-patches. But they are standarts in > every Flow Chart music software. We have to implement them :-) > > -ugur- > > On 2/8/06, Steven Yi <ste...@gm...> wrote: > > HI Ugur, > > > > It still seems to me that it is unecessary, but it might be how I am > > understanding the idea and what you have in mind may be different. To > > me, the Unit class should be text Csound code whose inputs and outputs > > are read either from the code or explicitly set using an editor. > > There doesn't seem to be a requirement for a sub-object for opcodes in > > this. When the patch is compiled, it shouldn't need to know the > > contents of the Unit, only how to take the inputs and outputs and hook > > them up, so no need to know anything about the opcodes used in it. If > > anything, I think the FlowGraph class could have sub-FlowGraph's, in > > the same way a PD patch can be standalone or be a subpatch to another > > patch. > > > > Am I misunderstanding what you have in mind? > > > > steven > > > > On 2/7/06, sokratesla <ugu...@gm...> wrote: > > > On 2/7/06, Steven Yi <ste...@gm...> wrote: > > > > Hi Ugur and all, > > > > > > > > I'm checking out the code that's going into CVS but am still confus= ed > > > > about the need for an Opcode class. I think the Unit class should = be > > > > enough to handle the abstraction of a single opcode or group of > > > > orchestra code. > > > > steven > > > > > > # Instead of having an array for opcode names, and an array of Ports > > > in the Unit, and finding out a way to link the opcodes with the > > > related opcode, I think, having an Opcode class which knows its outpu= t > > > and inputs ports and having a Unit which have an array of Opcodes is > > > easier to implement? Its very unnecessary when the Unit have only one > > > opcode but I thought that makes the life easier when there are more > > > than one opcodes, which may use the same Port etc. > > > # I surmised that it makes the structure more clear. Do you think tha= t > > > this classification unnecessary? > > > -ugur- > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642 > _______________________________________________ > Bluemusic-devel mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-devel > |
From: sokratesla <ugu...@gm...> - 2006-02-08 21:35:18
|
# I'm thinking about the final algorithm which generates the Csound code. If we determine it, it gets easier to set our classes. # The algorithm consists of two main parts: First "naming the Ports". Namely, all Ports have similar names "asig", "aout", "kenv", "ival" etc. First part will change them "a1", "a2", "a3", "k57" etc. (or if we want to struggle more, asig1, asig2, aout1, aout2...) # FlowGraph is responsible for the implementaion of this algorithm. # It'll use a recursive function for this purpose. # All Units are in an ArrayList in the FlowGraph. It starts to control from to first Unit wheter it is "checked". (checked means all of the Ports of this Unit is "named") If it isn't checked, the function looks to all output Ports that are connected to this Units input Ports. If all of them are named, it'll name the input Ports and check the Unit. # But if some of the output Ports that are connected to this Units input Ports are not named, the function will be applied to the owner Units of that output Ports. (here is the recursion, if I'm using the term correctly) So, the function go upwards through the Units until it finds a Unit of which input Ports are named, or which has no input Ports. # After all recursive functions are finished, FlowGraph turns to the first Unit in the ArrayList again and controls all of them whether they are checked. If it come across an unchecked Unit applies that recursive function on it and return to the first Unit. First part stops when the counter reaches to the end of Unit ArrayList. # So, all Ports are named with proper names. The remaining job is constructing the code from the contents of units in proper order. # I think, cutting the code into parts by using Port and Opcode classes will help at this part. # "Naming part" will change the names of the Ports. I suppose, it gets harder when a Unit have its piece of code as a String. If there are more than one row, namely more opcodes, in its code some of which have same input argument names, renaming them will be harder. Which input Port is related with which argument? This is the difficulty that I faced one day before submitting my Java project :-) Units had have only code Strings (no Ports, no Opcodes) and after every editing they have to constructing their IO's again. But then I realized that when I give the possibility of having more than one opcodes it isn't possible to reconstruct the code with appropriate variable names. # For the second part goes in reverse direction of the first part. (from above to downwards) It searches for a Unit which have no inputs, or constant inputs, or p-field initializations, and starts from that Unit. Write its code first, and check it. (now, checking means that, "its code is written, don't bother with it again") Then searchs for most above, unchecked Unit, and writes down its code... Until all Units are checked. # If we know explicitly which Opcode have which Ports, the reconstruction of the code will be extremely easy. # I didn't have thought about sub-patches. But they are standarts in every Flow Chart music software. We have to implement them :-) -ugur- On 2/8/06, Steven Yi <ste...@gm...> wrote: > HI Ugur, > > It still seems to me that it is unecessary, but it might be how I am > understanding the idea and what you have in mind may be different. To > me, the Unit class should be text Csound code whose inputs and outputs > are read either from the code or explicitly set using an editor. > There doesn't seem to be a requirement for a sub-object for opcodes in > this. When the patch is compiled, it shouldn't need to know the > contents of the Unit, only how to take the inputs and outputs and hook > them up, so no need to know anything about the opcodes used in it. If > anything, I think the FlowGraph class could have sub-FlowGraph's, in > the same way a PD patch can be standalone or be a subpatch to another > patch. > > Am I misunderstanding what you have in mind? > > steven > > On 2/7/06, sokratesla <ugu...@gm...> wrote: > > On 2/7/06, Steven Yi <ste...@gm...> wrote: > > > Hi Ugur and all, > > > > > > I'm checking out the code that's going into CVS but am still confused > > > about the need for an Opcode class. I think the Unit class should be > > > enough to handle the abstraction of a single opcode or group of > > > orchestra code. > > > steven > > > > # Instead of having an array for opcode names, and an array of Ports > > in the Unit, and finding out a way to link the opcodes with the > > related opcode, I think, having an Opcode class which knows its output > > and inputs ports and having a Unit which have an array of Opcodes is > > easier to implement? Its very unnecessary when the Unit have only one > > opcode but I thought that makes the life easier when there are more > > than one opcodes, which may use the same Port etc. > > # I surmised that it makes the structure more clear. Do you think that > > this classification unnecessary? > > -ugur- > > |
From: Steven Yi <ste...@gm...> - 2006-02-08 04:07:36
|
Hi Ugur, > # We've exchanged our ideas :-) I liked the idea of having an > expression object. As you know, at start, I considered the Unit as an > editable object too. But after making an Unit Library this will be > unnecessary, because one will have all opcodes at hand, and can write > its own Units. > # However, expressions are somewhat different. Its not possible to > prepare all mathematical expressions :-) of course. > # Two solutions have been mentioned and both of them can be applied. I > think, the one of the superiorities of Csound over other moduler music > softwares is its basis on text. Writing mathematical expressions with > keyboard, by typing, is easier than creating constant units, operator > units and connecting them with cables. > # We can prepare both an expression unit, and math units. The user can > choose s/he's own preference. > # And to reducing possible errors, expression unit can be constructed > so that it gets disabled when an uncorrect expression is written. > (like the disabled Units in the .jar file I first sent.) > # Certainly, we need a parser for the expression object. I can try to > write one, or we can you the parser you want to implement in the > Mixer. I think we can do an expression object that works like this (and requires no expression parser! =3D) ): -the expression object can be any code that is typed, something like this: (ival *45) + (kenv * 4) -the above, when the editing is done and the user presses enter, can be parsed to read what are the variables, then create input boxes depending on the values found. The output value rate can be intuited from the inputs (i.e. the case above, output would be k-rate because the expression is krate). -when the above goes to compile, the values can be replaced with the i- and k- values from the cables that hook up to it, and the following can be generated in the orch code: ktemp =3D (ival *45) + (kenv * 4) and the output value is the ktemp. That should work for expression ideas I think. > # Oww... When I started my Java project, I supposed that I'm the only > one who wants to write an GUI for Csound instruments. Then I heared > Cabel. And today I learned CSBlocks, and am suspicious about the > existenz of other interfaces :-) I feel very useless :-( Hardly! There was another modular java project donated to work with blue already, JavaOrc, but it was not easy for me to modify so I never got around to using it really (it is in the blue CVS in the plugins module, by the way, and may have good ideas to use). CSBlocks and Cabel both are not in Java and therefore unable to get hooked into blue; they are useful in themselves, but really for blue, it will be a very useful thing to have this in Java and to work within the blue environment. So I think your project will be very valuable and useful. =3D) > # Ok, Unit Library Editor should control wheter the arguments starts > with a, k, i, S, w or f. And these will be the types of a Port. Sounds good! steven |
From: Steven Yi <ste...@gm...> - 2006-02-08 03:55:41
|
HI Ugur, It still seems to me that it is unecessary, but it might be how I am understanding the idea and what you have in mind may be different. To me, the Unit class should be text Csound code whose inputs and outputs are read either from the code or explicitly set using an editor.=20 There doesn't seem to be a requirement for a sub-object for opcodes in this. When the patch is compiled, it shouldn't need to know the contents of the Unit, only how to take the inputs and outputs and hook them up, so no need to know anything about the opcodes used in it. If anything, I think the FlowGraph class could have sub-FlowGraph's, in the same way a PD patch can be standalone or be a subpatch to another patch. Am I misunderstanding what you have in mind? steven On 2/7/06, sokratesla <ugu...@gm...> wrote: > On 2/7/06, Steven Yi <ste...@gm...> wrote: > > Hi Ugur and all, > > > > I'm checking out the code that's going into CVS but am still confused > > about the need for an Opcode class. I think the Unit class should be > > enough to handle the abstraction of a single opcode or group of > > orchestra code. > > steven > > # Instead of having an array for opcode names, and an array of Ports > in the Unit, and finding out a way to link the opcodes with the > related opcode, I think, having an Opcode class which knows its output > and inputs ports and having a Unit which have an array of Opcodes is > easier to implement? Its very unnecessary when the Unit have only one > opcode but I thought that makes the life easier when there are more > than one opcodes, which may use the same Port etc. > # I surmised that it makes the structure more clear. Do you think that > this classification unnecessary? > -ugur- > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642 > _______________________________________________ > Bluemusic-devel mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-devel > |
From: sokratesla <ugu...@gm...> - 2006-02-07 20:42:33
|
On 2/7/06, Steven Yi <ste...@gm...> wrote: > Hi Ugur and all, > > I'm checking out the code that's going into CVS but am still confused > about the need for an Opcode class. I think the Unit class should be > enough to handle the abstraction of a single opcode or group of > orchestra code. > steven # Instead of having an array for opcode names, and an array of Ports in the Unit, and finding out a way to link the opcodes with the related opcode, I think, having an Opcode class which knows its output and inputs ports and having a Unit which have an array of Opcodes is easier to implement? Its very unnecessary when the Unit have only one opcode but I thought that makes the life easier when there are more than one opcodes, which may use the same Port etc. # I surmised that it makes the structure more clear. Do you think that this classification unnecessary? -ugur- |
From: sokratesla <ugu...@gm...> - 2006-02-07 18:36:15
|
On 2/6/06, Steven Yi <ste...@gm...> wrote: > I was thinking on the way to work today that perhaps expression > objects might not be the way to go. It makes it complicated and also > adds room for error on the user's part, and I think we need to limit > the possibilities of errors. > I think we should have a base Unit type. Instead of Expression > objects we should have Constant objects, similar to PD's number boxes. > The constant can output a-, k-, i-, or S- values. For expressions, I > think you were right in the beginning and it'll be better to do that > as a Unit so that the code is within the Unit and not accessible by > the user, so less chance of error. # We've exchanged our ideas :-) I liked the idea of having an expression object. As you know, at start, I considered the Unit as an editable object too. But after making an Unit Library this will be unnecessary, because one will have all opcodes at hand, and can write its own Units. # However, expressions are somewhat different. Its not possible to prepare all mathematical expressions :-) of course. # Two solutions have been mentioned and both of them can be applied. I think, the one of the superiorities of Csound over other moduler music softwares is its basis on text. Writing mathematical expressions with keyboard, by typing, is easier than creating constant units, operator units and connecting them with cables. # We can prepare both an expression unit, and math units. The user can choose s/he's own preference. # And to reducing possible errors, expression unit can be constructed so that it gets disabled when an uncorrect expression is written. (like the disabled Units in the .jar file I first sent.) # Certainly, we need a parser for the expression object. I can try to write one, or we can you the parser you want to implement in the Mixer. > I think we also need to make the abstractions very versatile such that > we can create all of the necessary parts from very few abstractions. > I have been thinking quite a bit about how PD and Reaktor work as well > as how Cabel is desgned. We should also look at CSBlocks as it is a > fairly well thought-out flow graph editing program for Csound. We also > need to take into account Csound inherent signal types and graph flow. # Oww... When I started my Java project, I supposed that I'm the only one who wants to write an GUI for Csound instruments. Then I heared Cabel. And today I learned CSBlocks, and am suspicious about the existenz of other interfaces :-) I feel very useless :-( > So, I am thinking that for Units, we need to be able to accept a-, k-, > i-, and S- type values (S- is a csound5-only string type). We should > also probably support w- and f- signal types too, but t- rate signals > from CsoundAV I think we should ignore as it is not available in any > other csound. # Ok, Unit Library Editor should control wheter the arguments starts with a, k, i, S, w or f. And these will be the types of a Port. -ugur- |
From: Steven Yi <ste...@gm...> - 2006-02-07 08:49:50
|
Hi Ugur and all, I'm checking out the code that's going into CVS but am still confused about the need for an Opcode class. I think the Unit class should be enough to handle the abstraction of a single opcode or group of orchestra code. Also, I don't know if it was in the email that you reported was blank, but I think maybe the expression class may not be the way to go, and better to use a Constant class, and to express math and such as you mentioned earlier as Unit's in themselves. Thanks! steven |
From: Steven Yi <ste...@gm...> - 2006-02-06 19:48:52
|
U3RyYW5nZSwgSSd2ZSBwYXN0ZWQgYmVsb3cgd2hhdCBJIHdyb3RlOgoKSGkgVWd1ciwKCkkgYXBv bG9naXplIGluIGFkdmFuY2UgSSdsbCBwcm9iYWJseSBiZSBhIGxpdHRsZSBzbG93IHRvIHJlcGx5 IHRvIHNvbWUKb2YgdGhlc2UgYXMgaXQgaXMgYSBiaWcgaXNzdWUgdG8gdGhpbmsgYWJvdXQgYXMg bGlrZSB5b3UgSSB3YW50IHRvIGdldAphIGdvb2Qgc2Vuc2Ugb2YgdGhlIGRlc2lnbiBiZWZvcmUg Y2hhcmdpbmcgaW50byBjb2RpbmcsIGFuZCBhbHNvCmJlY2F1c2UgSSB0aGluayB3ZSBzaG91bGQg dHJ5IHRvIG1ha2UgaXQgdmVyeSByb2J1c3Qgc28gdGhhdCB0aGUKaW5mcmFzdHJ1Y3R1cmUgd2ls bCBsYXN0IGEgbG9uZyB0aW1lLgoKSSB3YXMgdGhpbmtpbmcgb24gdGhlIHdheSB0byB3b3JrIHRv ZGF5IHRoYXQgcGVyaGFwcyBleHByZXNzaW9uCm9iamVjdHMgbWlnaHQgbm90IGJlIHRoZSB3YXkg dG8gZ28uICBJdCBtYWtlcyBpdCBjb21wbGljYXRlZCBhbmQgYWxzbwphZGRzIHJvb20gZm9yIGVy cm9yIG9uIHRoZSB1c2VyJ3MgcGFydCwgYW5kIEkgdGhpbmsgd2UgbmVlZCB0byBsaW1pdAp0aGUg cG9zc2liaWxpdGllcyBvZiBlcnJvcnMuCgpJIHRoaW5rIHdlIGFsc28gbmVlZCB0byBtYWtlIHRo ZSBhYnN0cmFjdGlvbnMgdmVyeSB2ZXJzYXRpbGUgc3VjaCB0aGF0CndlIGNhbiBjcmVhdGUgYWxs IG9mIHRoZSBuZWNlc3NhcnkgcGFydHMgZnJvbSB2ZXJ5IGZldyBhYnN0cmFjdGlvbnMuCkkgaGF2 ZSBiZWVuIHRoaW5raW5nIHF1aXRlIGEgYml0IGFib3V0IGhvdyBQRCBhbmQgUmVha3RvciB3b3Jr IGFzIHdlbGwKYXMgaG93IENhYmVsIGlzIGRlc2duZWQuIFdlIHNob3VsZCBhbHNvIGxvb2sgYXQg Q1NCbG9ja3MgYXMgaXQgaXMgYQpmYWlybHkgd2VsbCB0aG91Z2h0LW91dCBmbG93IGdyYXBoIGVk aXRpbmcgcHJvZ3JhbSBmb3IgQ3NvdW5kLiBXZSBhbHNvCm5lZWQgdG8gdGFrZSBpbnRvIGFjY291 bnQgQ3NvdW5kIGluaGVyZW50IHNpZ25hbCB0eXBlcyBhbmQgZ3JhcGggZmxvdy4KClNvLCBJIGFt IHRoaW5raW5nIHRoYXQgZm9yIFVuaXRzLCB3ZSBuZWVkIHRvIGJlIGFibGUgdG8gYWNjZXB0IGEt LCBrLSwKaS0sIGFuZCBTLSB0eXBlIHZhbHVlcyAoUy0gaXMgYSBjc291bmQ1LW9ubHkgc3RyaW5n IHR5cGUpLiAgV2Ugc2hvdWxkCmFsc28gcHJvYmFibHkgc3VwcG9ydCB3LSBhbmQgZi0gc2lnbmFs IHR5cGVzIHRvbywgYnV0IHQtIHJhdGUgc2lnbmFscwpmcm9tIENzb3VuZEFWIEkgdGhpbmsgd2Ug c2hvdWxkIGlnbm9yZSBhcyBpdCBpcyBub3QgYXZhaWxhYmxlIGluIGFueQpvdGhlciBjc291bmQu CgpJIHRoaW5rIHdlIHNob3VsZCBoYXZlIGEgYmFzZSBVbml0IHR5cGUuICBJbnN0ZWFkIG9mIEV4 cHJlc3Npb24Kb2JqZWN0cyB3ZSBzaG91bGQgaGF2ZSBDb25zdGFudCBvYmplY3RzLCBzaW1pbGFy IHRvIFBEJ3MgbnVtYmVyIGJveGVzLgogVGhlIGNvbnN0YW50IGNhbiBvdXRwdXQgYS0sIGstLCBp LSwgb3IgUy0gdmFsdWVzLiAgRm9yIGV4cHJlc3Npb25zLCBJCnRoaW5rIHlvdSB3ZXJlIHJpZ2h0 IGluIHRoZSBiZWdpbm5pbmcgYW5kIGl0J2xsIGJlIGJldHRlciB0byBkbyB0aGF0CmFzIGEgVW5p dCBzbyB0aGF0IHRoZSBjb2RlIGlzIHdpdGhpbiB0aGUgVW5pdCBhbmQgbm90IGFjY2Vzc2libGUg YnkKdGhlIHVzZXIsIHNvIGxlc3MgY2hhbmNlIG9mIGVycm9yLgoKSSBkbyBub3QgcXVpdGUgdW5k ZXJzdGFuZCB5b3VyIE9wY29kZSBjbGFzcyB5b3UgbWVudGlvbjsgSSB0aGluayB3ZQp3b24ndCBu ZWVkIHRoYXQgYXMgaXQgY2FuIGJlIGV4cHJlc3NhYmxlIHdpdGhpbiB0aGUgVW5pdCBjb25jZXB0 LgoKV2hhdCB3ZSBtaWdodCBuZWVkIGlzIHRoZSBwb3NzaWJpbGl0eSB0byBjcmVhdGUgc3VicGF0 Y2hlcywgYW5kIGlmIHNvLApwZXJoYXBzIHRoZXkgc2hvdWxkIGJlIGFkZGVkIHRvIGEgcHJvamVj dCdzIGxpYnJhcnksIGFzIHdlbGwgYXMKc2F2YWJsZSBpbiBhIHByb2dyYW0td2lkZSBsaWJyYXJ5 LiAgSSBhbSBjb25jZXJuZWQgdGhhdCBpZiB0aGUKc3VicGF0Y2hlcyBhcmUgbm90IHNhdmVkIHdp dGhpbiB0aGUgcHJvamVjdCB0aGF0IGl0IHdpbGwgaW50cm9kdWNlIGEKZGVwZW5kZW5jeSBwcm9i bGVtIHdoZW4gc2hhcmluZyB0aGUgcHJvamVjdCBvciB3aGVuIHJldHVybmluZyB0byB0aGUKcHJv amVjdCBhdCBhIGxhdGVyIHRpbWUuICBQZXJoYXBzIGJlc2lkZXMgdGhlIFVuaXRMaWJyYXJ5RWRp dG9yCmRpYWxvZywgd2Ugd2lsbCBuZWVkIGFub3RoZXIgZWRpdG9yIGZvciBzdWJwYXRjaGVzLgoK SSB0aGluayBpZiB3ZSBoYXZlIFVuaXQsIENvbnN0YW50LCBhbmQgUC1GaWVsZCBvYmplY3RzLCB0 aGF0IGNvdWxkCmNvdmVyIGEgbG90IG9mIGdyb3VuZC4gIFRoZW4gd2Ugd2lsbCBoYXZlIHRvIGNv dmVyIGNvbmRpdGlvbmFsIHVuaXRzCmZvciBpZi9lbHNlaWYvZWxzZSBjb25kaXRpb25zLCB3aGlj aCBjYW4gYmUgdmVyeSB0cmlja3kuICBQZXJoYXBzCmluc3RlYWQgb2YgUC1GaWVsZCBvYmplY3Rz IHdlIHNob3VsZCBoYXZlIElucHV0cyBhbmQgT3V0cHV0cywgc28gdGhhdAphbiBJbnN0cnVtZW50 IHBhdGNoIGNhbiBiZSBlYXNpbHkgcmV1c2VkIGFzIGEgc3VicGF0Y2guCgpMb3QncyB0byB0aGlu ayBhYm91dCEgIFdlIG1heSBzb29uIGhhdmUgZW5vdWdoIHRvIHN0YXJ0IHdvcmtpbmcgdGhvdWdo CmFuZCBwZXJoYXBzIGl0IG1pZ2h0IGJlIGdvb2QgdG8ganVzdCBidWlsZCBhd2F5IGEgZmlyc3Qg dmVyc2lvbiBhbmQKcGxheSB3aXRoIGl0IHRvIHRlc3Qgd2hhdCBpcyBnb29kIGFib3V0IHRoZSBk ZXNpZ24gYW5kIHdoYXQgaXMgbm90LAphbmQgcGxhbiB0byBnbyB0aHJvdWdoIGEgY291cGxlIG9y IGZldyBkZXNpZ25zIGJlZm9yZSBpdCBzdGFiaWxpemVzCmFuZCBiZWNvbWVzIHJlbGVhc2FibGUu CgpzdGV2ZW4KCnAucy4gLSBGbG93R3JhcGhJbnN0cnVtZW50IHNob3VsZCByZWFsbHkgYmUganVz dCBhIHRoaW4gd3JhcHBlciBmb3IKRmxvd0dyYXBoLCB3aGljaCB3aWxsIGJlIHJldXNhYmxlIGFt b25nc3Qgb3RoZXIgSW5zdHJ1bWVudCdzLgoKCgpPbiAyLzYvMDYsIHNva3JhdGVzbGEgPHVndXJn dW5leUBnbWFpbC5jb20+IHdyb3RlOgo+ICMgWW91ciBtYWlsIHdhcyBibGFuay4gUGVyaGFwcyBh biBlcnJvciBvY2N1cmVkIHdoaWxlIHlvdSBzZW50Lgo+IC11Z3VyCj4KPiBPbiAyLzMvMDYsIFN0 ZXZlbiBZaSA8c3RldmVueWlAZ21haWwuY29tPiB3cm90ZToKPiA+Cj4KPgo+IHNva3JhdGVzbGEg IHRvIGJsdWVtdXNpYy1kZXZlbAo+ICAgTW9yZSBvcHRpb25zICAgRmViIDIgKDQgZGF5cyBhZ28p Cj4KPiAjIEkgd2FudCB0byBtYWtlIGFsbCBjbGFzc2VzIGFuZCB0aGVpciByZXNwb3NpYmlsaXRp ZXMgY2xlYXIgYmVmb3JlCj4gc3RhcnRpbmcgdG8gY29kZS4gSSB0aGluayB0aGlzIHRoaW5raW5n IHByb2Nlc3MgaXMgbW9yZSBpbXBvcnRhbnQgdGhhbgo+IHdyaXRpbmcgdGhlIGNvZGVzLiBBZnRl ciB0aGUgc3BlY2lmaWNhdGlvbiwgdGhlIGltcGxlbWVudGF0aW9ucyB3aWxsCj4gYmUgZWFzaWVy IHRoYW4gcG9uZGVyaW5nIGJlZm9yZSB0aGUgc2NyZWVuLiBTbywgdGhpcyBpcyB0aGUKPiBleHBs YW5hdGlvbiB3aHkgSSBhbSB0YWxraW5nIHRvIG11Y2ggYnV0IGRvZXNuJ3Qgd3JpdGUgYW55IGNv ZGUgOi0pCj4KPiAjIEknbSBtYWtpbmcgYSBjaGFydCBvZiBjbGFzc2VzIGFuZCB0aGVpciByZXNw b25zaWJpbGl0aWVzOgo+Cj4gIyBQb3J0Ogo+ICMgVGhpcyBjbGFzcyB3YXMgbm90IGluIG15IHBy b2plY3QsIGJ1dCBhZnRlciBhIHdoaWxlIEkgc3Ryb25nbHkgZmVlbAo+IGl0cyBuZWNlc3NpdHku Cj4gIyBBIFBvcnQgc2hvdWxkIGtub3cgd2hldGVyIGl0IGlzIG91dHB1dCBvciBpbnB1dCwgdG8g d2hpY2ggT3Bjb2RlCj4gKGFuZCBVbml0KSBpdCBiZWxvbmdzLCB3aGV0aGVyIGEgQ2FibGUgaXMg cGx1Z2dlZCB0byBpdCwgaWYgeWVzLCB0bwo+IHdoaWNoIG90aGVyIHBvcnRzIGl0IGlzIGNvbm5u ZWN0ZWQuIChhbiBvdXRwdXQgUG9ydCBtYXkgYmUgY29ubmVjdGVkCj4gdG8gbWFueSBpbnB1dCBw b3J0cykKPiAjIFRoaXMgY2xhc3Mgd2lsbCBiZSB2ZXJ5IHVzZWZ1bCBhdCB0aGUgZW5kLCB3aGVu IGl0IGNvbWVzIHRvIGNyZWF0ZQo+IHRoZSBDc291bmQgY29kZS4gKEZ1cnRoZXJtb3JlIHdoZW4g dGhpcyD9bnB1dC9vdXRwdXRzIGFyZSBkZWZpbmVkIGFzCj4gZXhwbGljaXQgY2xhc3NlcywgaXQn bGwgZ2V0IGVhc2llciB0byBkZXRlY3QgZGV0ZXJtaW5lIHdoZXRlciBtb3VzZQo+IGNsaWNrZWQg b24gaXQgZXRjLikKPiAjIEV2ZXJ5IHBvcnQgaXMgcmVsYXRlZCB3aXRoIHZhcmlhYmxlIHJhdGUg dHlwZSwgYW5kIGEgbmFtZS4gVGhlIG5hbWUKPiB3aWxsIGJlIHRoZSBhcmd1bWVudHMgZm9yIGVh Y2ggb3Bjb2RlIGluIHRoZSBtYW51YWwuIERpZmZlcmVudCB0eXBlcwo+IGNhbm5vdCBiZSBjb25u ZWN0ZWQuCj4KPiAjIE9wY29kZTogKHRoaXMgY29tZXMgdG8gbXkgbWluZCBub3cpCj4gIyBPcGNv ZGUgaGFzIG9uZSBvdXRwdXQgcG9ydCAoaWYgbmVjZXNzYXJ5KSBhbmQgb25lIG9yIG1vcmUgaW5w dXQKPiBwb3J0cyAoaWYgbmVjZXNzYXJ5KSwgaGFzIGEgbmFtZSBhbmQga25vd3MgdG8gd2hpY2gg VW5pdCBpdCBiZWxvbmdzLgo+Cj4gIyBVbml0Ogo+ICMgVGhlcmUgYXJlIHR3byB0eXBlcyBvZiB1 bml0czogRXhwcmVzc2lvbnMgYW5kIFVuaXRzLgo+ICMgVW5pdCdzIGhhdmUgYW4gYXJyYXkgb2Yg T3Bjb2RlcywgaGFzIGEgcG9zaXRpb24sIGhhcyBhIG5hbWUgYW5kCj4gY29tbWVudGkga25vd3Mg ZWl0aGVyIGl0IHdpbGwgZ2V0IGEgaW5saW5lIGNvZGUgb3IgYSBVRE8uCj4gIyBFeHByZXNzaW9u cyBoYXZlIGEgZXhwcmVzc2lvbkV2YWx1YXRvciBtZXRob2QuIEFjY29yZGluZyB0aGUKPiBtYXRo ZW1hdGljYWwgZXhwcmVzc2lvbiBnYXZlIHRvIHRoYXQgbWV0aG9kIGl0IHNldHMgcHJvcGVyIHBv cnRzLgo+Cj4gIyBDYWJsZToKPiAjIEEgQ2FibGUga25vd3MgYmV0d2VlbiB3aGljaCBpbnB1dCBh bmQgb3V0cHV0IHBvcnRzIGl0IGlzIGNvbm5lY3RlZC4KPgo+ICMgRmxvd0dyYXBoSW5zdHJ1bWVu dDoKPiAjIEl0IGhhcyBVbml0cyBhbmQgQ2FibGVzLiBJdHMgYWRkQ2FibGUgbWV0aG9kIGlzIHJl c3BvbnNpYmxlIGZvcgo+IGNvcnJlY3QgY29ubmVjdGlvbnMuCj4gaW50IGFkZENhYmxlKFBvcnQg aW5wdXQsIFBvcnQgb3V0cHV0KTsKPiByZXR1cm5zIE9VVF9UT19PVVQgb3Igc2ltaWxhciBzdGF0 aWMgaW50IHZhbHVlcyBhY2NvcmRpbmcgdG8gZmFsc2UKPiBjb25uZWN0aW9ucywgQ09OTkVDVEVE IGZvciBjb3JyZWN0IG9uZXMgZXRjLgo+ICMgYW5kIGZpbmFsbHkgdGhlIGhhcmRlc3QgbWV0aG9k OiBwdWJsaWMgU3RyaW5nIGdlbmVyYXRlSW5zdHJ1bWVudCgpCj4gd2hpY2gsIGlmIEkgdW5kZXJz dG9vZCBjb3JyZWN0bHksIGdlbmVyYXRlcyB0aGUgQ3NvdW5kIGluc3RydW1lbnQgY29kZSEKPgo+ ICMgVGhpcyBpcyB0aGUgZHJhZnQgc3RydWN0dXJlIEkgdGhpbmsgdG8gYnVpbGQuIERvIHlvdSBo YXZlIGFueQo+IG9iamVjdGlvbnMsIG9yIHByb3BlcnRpZXMgd2FudCB0byBhZGQuCj4gIyBuZXh0 IEknbGwgc2VuZCBhIG1haWwgYWJvdXQgdGhlIGNsYXNzZXMgb2YgZ3JhcGhpY2FsIGludGVyZmFj ZS4KPgo+IC11Z3VyLQo+Cg== |
From: Steven Yi <ste...@gm...> - 2006-02-06 18:26:38
|
I was going to ignore macros as I don't support their usage in general in blue (at least, haven't made any effort or have had any desire to do so). Without macros, it's not so bad I think. steven On 2/6/06, Michael Bechard <got...@ya...> wrote: > That could get pretty sticky, given that those kinds > of evaluations also accept input from macros. How do > you intend to handle that? > > Michael Bechard > > --- Steven Yi <ste...@gm...> wrote: > > > Hi All, > > > > I'm currently looking for a parser or expression > > evaluation engine > > that is modifiable that will be able to parse Csound > > Score Expressions > > as listed at: > > > > http://www.csounds.com/manual/html/ScoreEval.html > > > > A small calculator parser that handles -, +, *, /, > > and parenthesis > > should be fine and easy to modify too. If anyone > > happens to know of > > one or has coded one and it is GPL, please contact > > me as I am looking > > to add evaluation of score expressions to blue which > > I need to do to > > get generate an accurate mixer instrument note > > statement. I am > > looking for a hand coded parser in particular as I > > am not particularly > > interested at this time to add Antlr or JavaCC or > > JCup parsers to > > blue's build system nor add them as runtime library > > dependencies, > > which they require for running parsers generated by > > them. > > > > Also, in general, if anyone has any experience with > > parser generators > > as in the above and could comment on the above, > > please do. =3D) I've > > experimented with Antlr a few times and am going to > > take a look at > > JavaCC I think sometime this week. > > > > Thanks, > > steven > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do > > you grep through log files > > for problems? Stop! Download the new AJAX search > > engine that makes > > searching your log files as easy as surfing the > > web. DOWNLOAD SPLUNK! > > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=103432&bid#0486&dat=121642 > > _______________________________________________ > > Bluemusic-devel mailing list > > Blu...@li... > > > https://lists.sourceforge.net/lists/listinfo/bluemusic-devel > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > _______________________________________________ > Bluemusic-devel mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-devel > |
From: Michael B. <got...@ya...> - 2006-02-06 14:00:07
|
That could get pretty sticky, given that those kinds of evaluations also accept input from macros. How do you intend to handle that? Michael Bechard --- Steven Yi <ste...@gm...> wrote: > Hi All, > > I'm currently looking for a parser or expression > evaluation engine > that is modifiable that will be able to parse Csound > Score Expressions > as listed at: > > http://www.csounds.com/manual/html/ScoreEval.html > > A small calculator parser that handles -, +, *, /, > and parenthesis > should be fine and easy to modify too. If anyone > happens to know of > one or has coded one and it is GPL, please contact > me as I am looking > to add evaluation of score expressions to blue which > I need to do to > get generate an accurate mixer instrument note > statement. I am > looking for a hand coded parser in particular as I > am not particularly > interested at this time to add Antlr or JavaCC or > JCup parsers to > blue's build system nor add them as runtime library > dependencies, > which they require for running parsers generated by > them. > > Also, in general, if anyone has any experience with > parser generators > as in the above and could comment on the above, > please do. =) I've > experimented with Antlr a few times and am going to > take a look at > JavaCC I think sometime this week. > > Thanks, > steven > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do > you grep through log files > for problems? Stop! Download the new AJAX search > engine that makes > searching your log files as easy as surfing the > web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 > _______________________________________________ > Bluemusic-devel mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-devel > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Steven Yi <ste...@gm...> - 2006-02-06 04:14:42
|
Hi All, I'm currently looking for a parser or expression evaluation engine that is modifiable that will be able to parse Csound Score Expressions as listed at: http://www.csounds.com/manual/html/ScoreEval.html A small calculator parser that handles -, +, *, /, and parenthesis should be fine and easy to modify too. If anyone happens to know of one or has coded one and it is GPL, please contact me as I am looking to add evaluation of score expressions to blue which I need to do to get generate an accurate mixer instrument note statement. I am looking for a hand coded parser in particular as I am not particularly interested at this time to add Antlr or JavaCC or JCup parsers to blue's build system nor add them as runtime library dependencies, which they require for running parsers generated by them. Also, in general, if anyone has any experience with parser generators as in the above and could comment on the above, please do. =3D) I've experimented with Antlr a few times and am going to take a look at JavaCC I think sometime this week. Thanks, steven |
From: Steven Yi <ste...@gm...> - 2006-02-03 06:42:36
|
SGkgVWd1ciwKCkkgYXBvbG9naXplIGluIGFkdmFuY2UgSSdsbCBwcm9iYWJseSBiZSBhIGxpdHRs ZSBzbG93IHRvIHJlcGx5IHRvIHNvbWUKb2YgdGhlc2UgYXMgaXQgaXMgYSBiaWcgaXNzdWUgdG8g dGhpbmsgYWJvdXQgYXMgbGlrZSB5b3UgSSB3YW50IHRvIGdldAphIGdvb2Qgc2Vuc2Ugb2YgdGhl IGRlc2lnbiBiZWZvcmUgY2hhcmdpbmcgaW50byBjb2RpbmcsIGFuZCBhbHNvCmJlY2F1c2UgSSB0 aGluayB3ZSBzaG91bGQgdHJ5IHRvIG1ha2UgaXQgdmVyeSByb2J1c3Qgc28gdGhhdCB0aGUKaW5m cmFzdHJ1Y3R1cmUgd2lsbCBsYXN0IGEgbG9uZyB0aW1lLgoKSSB3YXMgdGhpbmtpbmcgb24gdGhl IHdheSB0byB3b3JrIHRvZGF5IHRoYXQgcGVyaGFwcyBleHByZXNzaW9uCm9iamVjdHMgbWlnaHQg bm90IGJlIHRoZSB3YXkgdG8gZ28uICBJdCBtYWtlcyBpdCBjb21wbGljYXRlZCBhbmQgYWxzbwph ZGRzIHJvb20gZm9yIGVycm9yIG9uIHRoZSB1c2VyJ3MgcGFydCwgYW5kIEkgdGhpbmsgd2UgbmVl ZCB0byBsaW1pdAp0aGUgcG9zc2liaWxpdGllcyBvZiBlcnJvcnMuCgpJIHRoaW5rIHdlIGFsc28g bmVlZCB0byBtYWtlIHRoZSBhYnN0cmFjdGlvbnMgdmVyeSB2ZXJzYXRpbGUgc3VjaCB0aGF0Cndl IGNhbiBjcmVhdGUgYWxsIG9mIHRoZSBuZWNlc3NhcnkgcGFydHMgZnJvbSB2ZXJ5IGZldyBhYnN0 cmFjdGlvbnMuIApJIGhhdmUgYmVlbiB0aGlua2luZyBxdWl0ZSBhIGJpdCBhYm91dCBob3cgUEQg YW5kIFJlYWt0b3Igd29yayBhcyB3ZWxsCmFzIGhvdyBDYWJlbCBpcyBkZXNnbmVkLiBXZSBzaG91 bGQgYWxzbyBsb29rIGF0IENTQmxvY2tzIGFzIGl0IGlzIGEKZmFpcmx5IHdlbGwgdGhvdWdodC1v dXQgZmxvdyBncmFwaCBlZGl0aW5nIHByb2dyYW0gZm9yIENzb3VuZC4gV2UgYWxzbwpuZWVkIHRv IHRha2UgaW50byBhY2NvdW50IENzb3VuZCBpbmhlcmVudCBzaWduYWwgdHlwZXMgYW5kIGdyYXBo IGZsb3cuCgpTbywgSSBhbSB0aGlua2luZyB0aGF0IGZvciBVbml0cywgd2UgbmVlZCB0byBiZSBh YmxlIHRvIGFjY2VwdCBhLSwgay0sCmktLCBhbmQgUy0gdHlwZSB2YWx1ZXMgKFMtIGlzIGEgY3Nv dW5kNS1vbmx5IHN0cmluZyB0eXBlKS4gIFdlIHNob3VsZAphbHNvIHByb2JhYmx5IHN1cHBvcnQg dy0gYW5kIGYtIHNpZ25hbCB0eXBlcyB0b28sIGJ1dCB0LSByYXRlIHNpZ25hbHMKZnJvbSBDc291 bmRBViBJIHRoaW5rIHdlIHNob3VsZCBpZ25vcmUgYXMgaXQgaXMgbm90IGF2YWlsYWJsZSBpbiBh bnkKb3RoZXIgY3NvdW5kLgoKSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIGJhc2UgVW5pdCB0eXBl LiAgSW5zdGVhZCBvZiBFeHByZXNzaW9uCm9iamVjdHMgd2Ugc2hvdWxkIGhhdmUgQ29uc3RhbnQg b2JqZWN0cywgc2ltaWxhciB0byBQRCdzIG51bWJlciBib3hlcy4KIFRoZSBjb25zdGFudCBjYW4g b3V0cHV0IGEtLCBrLSwgaS0sIG9yIFMtIHZhbHVlcy4gIEZvciBleHByZXNzaW9ucywgSQp0aGlu ayB5b3Ugd2VyZSByaWdodCBpbiB0aGUgYmVnaW5uaW5nIGFuZCBpdCdsbCBiZSBiZXR0ZXIgdG8g ZG8gdGhhdAphcyBhIFVuaXQgc28gdGhhdCB0aGUgY29kZSBpcyB3aXRoaW4gdGhlIFVuaXQgYW5k IG5vdCBhY2Nlc3NpYmxlIGJ5CnRoZSB1c2VyLCBzbyBsZXNzIGNoYW5jZSBvZiBlcnJvci4KCkkg ZG8gbm90IHF1aXRlIHVuZGVyc3RhbmQgeW91ciBPcGNvZGUgY2xhc3MgeW91IG1lbnRpb247IEkg dGhpbmsgd2UKd29uJ3QgbmVlZCB0aGF0IGFzIGl0IGNhbiBiZSBleHByZXNzYWJsZSB3aXRoaW4g dGhlIFVuaXQgY29uY2VwdC4KCldoYXQgd2UgbWlnaHQgbmVlZCBpcyB0aGUgcG9zc2liaWxpdHkg dG8gY3JlYXRlIHN1YnBhdGNoZXMsIGFuZCBpZiBzbywKcGVyaGFwcyB0aGV5IHNob3VsZCBiZSBh ZGRlZCB0byBhIHByb2plY3QncyBsaWJyYXJ5LCBhcyB3ZWxsIGFzCnNhdmFibGUgaW4gYSBwcm9n cmFtLXdpZGUgbGlicmFyeS4gIEkgYW0gY29uY2VybmVkIHRoYXQgaWYgdGhlCnN1YnBhdGNoZXMg YXJlIG5vdCBzYXZlZCB3aXRoaW4gdGhlIHByb2plY3QgdGhhdCBpdCB3aWxsIGludHJvZHVjZSBh CmRlcGVuZGVuY3kgcHJvYmxlbSB3aGVuIHNoYXJpbmcgdGhlIHByb2plY3Qgb3Igd2hlbiByZXR1 cm5pbmcgdG8gdGhlCnByb2plY3QgYXQgYSBsYXRlciB0aW1lLiAgUGVyaGFwcyBiZXNpZGVzIHRo ZSBVbml0TGlicmFyeUVkaXRvcgpkaWFsb2csIHdlIHdpbGwgbmVlZCBhbm90aGVyIGVkaXRvciBm b3Igc3VicGF0Y2hlcy4KCkkgdGhpbmsgaWYgd2UgaGF2ZSBVbml0LCBDb25zdGFudCwgYW5kIFAt RmllbGQgb2JqZWN0cywgdGhhdCBjb3VsZApjb3ZlciBhIGxvdCBvZiBncm91bmQuICBUaGVuIHdl IHdpbGwgaGF2ZSB0byBjb3ZlciBjb25kaXRpb25hbCB1bml0cwpmb3IgaWYvZWxzZWlmL2Vsc2Ug Y29uZGl0aW9ucywgd2hpY2ggY2FuIGJlIHZlcnkgdHJpY2t5LiAgUGVyaGFwcwppbnN0ZWFkIG9m IFAtRmllbGQgb2JqZWN0cyB3ZSBzaG91bGQgaGF2ZSBJbnB1dHMgYW5kIE91dHB1dHMsIHNvIHRo YXQKYW4gSW5zdHJ1bWVudCBwYXRjaCBjYW4gYmUgZWFzaWx5IHJldXNlZCBhcyBhIHN1YnBhdGNo LgoKTG90J3MgdG8gdGhpbmsgYWJvdXQhICBXZSBtYXkgc29vbiBoYXZlIGVub3VnaCB0byBzdGFy dCB3b3JraW5nIHRob3VnaAphbmQgcGVyaGFwcyBpdCBtaWdodCBiZSBnb29kIHRvIGp1c3QgYnVp bGQgYXdheSBhIGZpcnN0IHZlcnNpb24gYW5kCnBsYXkgd2l0aCBpdCB0byB0ZXN0IHdoYXQgaXMg Z29vZCBhYm91dCB0aGUgZGVzaWduIGFuZCB3aGF0IGlzIG5vdCwKYW5kIHBsYW4gdG8gZ28gdGhy b3VnaCBhIGNvdXBsZSBvciBmZXcgZGVzaWducyBiZWZvcmUgaXQgc3RhYmlsaXplcwphbmQgYmVj b21lcyByZWxlYXNhYmxlLgoKc3RldmVuCgpwLnMuIC0gRmxvd0dyYXBoSW5zdHJ1bWVudCBzaG91 bGQgcmVhbGx5IGJlIGp1c3QgYSB0aGluIHdyYXBwZXIgZm9yCkZsb3dHcmFwaCwgd2hpY2ggd2ls bCBiZSByZXVzYWJsZSBhbW9uZ3N0IG90aGVyIEluc3RydW1lbnQncy4KCgpPbiAyLzIvMDYsIHNv a3JhdGVzbGEgPHVndXJndW5leUBnbWFpbC5jb20+IHdyb3RlOgo+ICMgSSB3YW50IHRvIG1ha2Ug YWxsIGNsYXNzZXMgYW5kIHRoZWlyIHJlc3Bvc2liaWxpdGllcyBjbGVhciBiZWZvcmUKPiBzdGFy dGluZyB0byBjb2RlLiBJIHRoaW5rIHRoaXMgdGhpbmtpbmcgcHJvY2VzcyBpcyBtb3JlIGltcG9y dGFudCB0aGFuCj4gd3JpdGluZyB0aGUgY29kZXMuIEFmdGVyIHRoZSBzcGVjaWZpY2F0aW9uLCB0 aGUgaW1wbGVtZW50YXRpb25zIHdpbGwKPiBiZSBlYXNpZXIgdGhhbiBwb25kZXJpbmcgYmVmb3Jl IHRoZSBzY3JlZW4uIFNvLCB0aGlzIGlzIHRoZQo+IGV4cGxhbmF0aW9uIHdoeSBJIGFtIHRhbGtp bmcgdG8gbXVjaCBidXQgZG9lc24ndCB3cml0ZSBhbnkgY29kZSA6LSkKPgo+ICMgSSdtIG1ha2lu ZyBhIGNoYXJ0IG9mIGNsYXNzZXMgYW5kIHRoZWlyIHJlc3BvbnNpYmlsaXRpZXM6Cj4KPiAjIFBv cnQ6Cj4gIyBUaGlzIGNsYXNzIHdhcyBub3QgaW4gbXkgcHJvamVjdCwgYnV0IGFmdGVyIGEgd2hp bGUgSSBzdHJvbmdseSBmZWVsCj4gaXRzIG5lY2Vzc2l0eS4KPiAjIEEgUG9ydCBzaG91bGQga25v dyB3aGV0ZXIgaXQgaXMgb3V0cHV0IG9yIGlucHV0LCB0byB3aGljaCBPcGNvZGUKPiAoYW5kIFVu aXQpIGl0IGJlbG9uZ3MsIHdoZXRoZXIgYSBDYWJsZSBpcyBwbHVnZ2VkIHRvIGl0LCBpZiB5ZXMs IHRvCj4gd2hpY2ggb3RoZXIgcG9ydHMgaXQgaXMgY29ubm5lY3RlZC4gKGFuIG91dHB1dCBQb3J0 IG1heSBiZSBjb25uZWN0ZWQKPiB0byBtYW55IGlucHV0IHBvcnRzKQo+ICMgVGhpcyBjbGFzcyB3 aWxsIGJlIHZlcnkgdXNlZnVsIGF0IHRoZSBlbmQsIHdoZW4gaXQgY29tZXMgdG8gY3JlYXRlCj4g dGhlIENzb3VuZCBjb2RlLiAoRnVydGhlcm1vcmUgd2hlbiB0aGlzIP1ucHV0L291dHB1dHMgYXJl IGRlZmluZWQgYXMKPiBleHBsaWNpdCBjbGFzc2VzLCBpdCdsbCBnZXQgZWFzaWVyIHRvIGRldGVj dCBkZXRlcm1pbmUgd2hldGVyIG1vdXNlCj4gY2xpY2tlZCBvbiBpdCBldGMuKQo+ICMgRXZlcnkg cG9ydCBpcyByZWxhdGVkIHdpdGggdmFyaWFibGUgcmF0ZSB0eXBlLCBhbmQgYSBuYW1lLiBUaGUg bmFtZQo+IHdpbGwgYmUgdGhlIGFyZ3VtZW50cyBmb3IgZWFjaCBvcGNvZGUgaW4gdGhlIG1hbnVh bC4gRGlmZmVyZW50IHR5cGVzCj4gY2Fubm90IGJlIGNvbm5lY3RlZC4KPgo+ICMgT3Bjb2RlOiAo dGhpcyBjb21lcyB0byBteSBtaW5kIG5vdykKPiAjIE9wY29kZSBoYXMgb25lIG91dHB1dCBwb3J0 IChpZiBuZWNlc3NhcnkpIGFuZCBvbmUgb3IgbW9yZSBpbnB1dAo+IHBvcnRzIChpZiBuZWNlc3Nh cnkpLCBoYXMgYSBuYW1lIGFuZCBrbm93cyB0byB3aGljaCBVbml0IGl0IGJlbG9uZ3MuCj4KPiAj IFVuaXQ6Cj4gIyBUaGVyZSBhcmUgdHdvIHR5cGVzIG9mIHVuaXRzOiBFeHByZXNzaW9ucyBhbmQg VW5pdHMuCj4gIyBVbml0J3MgaGF2ZSBhbiBhcnJheSBvZiBPcGNvZGVzLCBoYXMgYSBwb3NpdGlv biwgaGFzIGEgbmFtZSBhbmQKPiBjb21tZW50aSBrbm93cyBlaXRoZXIgaXQgd2lsbCBnZXQgYSBp bmxpbmUgY29kZSBvciBhIFVETy4KPiAjIEV4cHJlc3Npb25zIGhhdmUgYSBleHByZXNzaW9uRXZh bHVhdG9yIG1ldGhvZC4gQWNjb3JkaW5nIHRoZQo+IG1hdGhlbWF0aWNhbCBleHByZXNzaW9uIGdh dmUgdG8gdGhhdCBtZXRob2QgaXQgc2V0cyBwcm9wZXIgcG9ydHMuCj4KPiAjIENhYmxlOgo+ICMg QSBDYWJsZSBrbm93cyBiZXR3ZWVuIHdoaWNoIGlucHV0IGFuZCBvdXRwdXQgcG9ydHMgaXQgaXMg Y29ubmVjdGVkLgo+Cj4gIyBGbG93R3JhcGhJbnN0cnVtZW50Ogo+ICMgSXQgaGFzIFVuaXRzIGFu ZCBDYWJsZXMuIEl0cyBhZGRDYWJsZSBtZXRob2QgaXMgcmVzcG9uc2libGUgZm9yCj4gY29ycmVj dCBjb25uZWN0aW9ucy4KPiBpbnQgYWRkQ2FibGUoUG9ydCBpbnB1dCwgUG9ydCBvdXRwdXQpOwo+ IHJldHVybnMgT1VUX1RPX09VVCBvciBzaW1pbGFyIHN0YXRpYyBpbnQgdmFsdWVzIGFjY29yZGlu ZyB0byBmYWxzZQo+IGNvbm5lY3Rpb25zLCBDT05ORUNURUQgZm9yIGNvcnJlY3Qgb25lcyBldGMu Cj4gIyBhbmQgZmluYWxseSB0aGUgaGFyZGVzdCBtZXRob2Q6IHB1YmxpYyBTdHJpbmcgZ2VuZXJh dGVJbnN0cnVtZW50KCkKPiB3aGljaCwgaWYgSSB1bmRlcnN0b29kIGNvcnJlY3RseSwgZ2VuZXJh dGVzIHRoZSBDc291bmQgaW5zdHJ1bWVudCBjb2RlIQo+Cj4gIyBUaGlzIGlzIHRoZSBkcmFmdCBz dHJ1Y3R1cmUgSSB0aGluayB0byBidWlsZC4gRG8geW91IGhhdmUgYW55Cj4gb2JqZWN0aW9ucywg b3IgcHJvcGVydGllcyB3YW50IHRvIGFkZC4KPiAjIG5leHQgSSdsbCBzZW5kIGEgbWFpbCBhYm91 dCB0aGUgY2xhc3NlcyBvZiBncmFwaGljYWwgaW50ZXJmYWNlLgo+Cj4gLXVndXItCj4K |
From: sokratesla <ugu...@gm...> - 2006-02-02 17:09:34
|
IyBJIHdhbnQgdG8gbWFrZSBhbGwgY2xhc3NlcyBhbmQgdGhlaXIgcmVzcG9zaWJpbGl0aWVzIGNs ZWFyIGJlZm9yZQpzdGFydGluZyB0byBjb2RlLiBJIHRoaW5rIHRoaXMgdGhpbmtpbmcgcHJvY2Vz cyBpcyBtb3JlIGltcG9ydGFudCB0aGFuCndyaXRpbmcgdGhlIGNvZGVzLiBBZnRlciB0aGUgc3Bl Y2lmaWNhdGlvbiwgdGhlIGltcGxlbWVudGF0aW9ucyB3aWxsCmJlIGVhc2llciB0aGFuIHBvbmRl cmluZyBiZWZvcmUgdGhlIHNjcmVlbi4gU28sIHRoaXMgaXMgdGhlCmV4cGxhbmF0aW9uIHdoeSBJ IGFtIHRhbGtpbmcgdG8gbXVjaCBidXQgZG9lc24ndCB3cml0ZSBhbnkgY29kZSA6LSkKCiMgSSdt IG1ha2luZyBhIGNoYXJ0IG9mIGNsYXNzZXMgYW5kIHRoZWlyIHJlc3BvbnNpYmlsaXRpZXM6Cgoj IFBvcnQ6CiMgVGhpcyBjbGFzcyB3YXMgbm90IGluIG15IHByb2plY3QsIGJ1dCBhZnRlciBhIHdo aWxlIEkgc3Ryb25nbHkgZmVlbAppdHMgbmVjZXNzaXR5LgojIEEgUG9ydCBzaG91bGQga25vdyB3 aGV0ZXIgaXQgaXMgb3V0cHV0IG9yIGlucHV0LCB0byB3aGljaCBPcGNvZGUKKGFuZCBVbml0KSBp dCBiZWxvbmdzLCB3aGV0aGVyIGEgQ2FibGUgaXMgcGx1Z2dlZCB0byBpdCwgaWYgeWVzLCB0bwp3 aGljaCBvdGhlciBwb3J0cyBpdCBpcyBjb25ubmVjdGVkLiAoYW4gb3V0cHV0IFBvcnQgbWF5IGJl IGNvbm5lY3RlZAp0byBtYW55IGlucHV0IHBvcnRzKQojIFRoaXMgY2xhc3Mgd2lsbCBiZSB2ZXJ5 IHVzZWZ1bCBhdCB0aGUgZW5kLCB3aGVuIGl0IGNvbWVzIHRvIGNyZWF0ZQp0aGUgQ3NvdW5kIGNv ZGUuIChGdXJ0aGVybW9yZSB3aGVuIHRoaXMg/W5wdXQvb3V0cHV0cyBhcmUgZGVmaW5lZCBhcwpl eHBsaWNpdCBjbGFzc2VzLCBpdCdsbCBnZXQgZWFzaWVyIHRvIGRldGVjdCBkZXRlcm1pbmUgd2hl dGVyIG1vdXNlCmNsaWNrZWQgb24gaXQgZXRjLikKIyBFdmVyeSBwb3J0IGlzIHJlbGF0ZWQgd2l0 aCB2YXJpYWJsZSByYXRlIHR5cGUsIGFuZCBhIG5hbWUuIFRoZSBuYW1lCndpbGwgYmUgdGhlIGFy Z3VtZW50cyBmb3IgZWFjaCBvcGNvZGUgaW4gdGhlIG1hbnVhbC4gRGlmZmVyZW50IHR5cGVzCmNh bm5vdCBiZSBjb25uZWN0ZWQuCgojIE9wY29kZTogKHRoaXMgY29tZXMgdG8gbXkgbWluZCBub3cp CiMgT3Bjb2RlIGhhcyBvbmUgb3V0cHV0IHBvcnQgKGlmIG5lY2Vzc2FyeSkgYW5kIG9uZSBvciBt b3JlIGlucHV0CnBvcnRzIChpZiBuZWNlc3NhcnkpLCBoYXMgYSBuYW1lIGFuZCBrbm93cyB0byB3 aGljaCBVbml0IGl0IGJlbG9uZ3MuCgojIFVuaXQ6CiMgVGhlcmUgYXJlIHR3byB0eXBlcyBvZiB1 bml0czogRXhwcmVzc2lvbnMgYW5kIFVuaXRzLgojIFVuaXQncyBoYXZlIGFuIGFycmF5IG9mIE9w Y29kZXMsIGhhcyBhIHBvc2l0aW9uLCBoYXMgYSBuYW1lIGFuZApjb21tZW50aSBrbm93cyBlaXRo ZXIgaXQgd2lsbCBnZXQgYSBpbmxpbmUgY29kZSBvciBhIFVETy4KIyBFeHByZXNzaW9ucyBoYXZl IGEgZXhwcmVzc2lvbkV2YWx1YXRvciBtZXRob2QuIEFjY29yZGluZyB0aGUKbWF0aGVtYXRpY2Fs IGV4cHJlc3Npb24gZ2F2ZSB0byB0aGF0IG1ldGhvZCBpdCBzZXRzIHByb3BlciBwb3J0cy4KCiMg Q2FibGU6CiMgQSBDYWJsZSBrbm93cyBiZXR3ZWVuIHdoaWNoIGlucHV0IGFuZCBvdXRwdXQgcG9y dHMgaXQgaXMgY29ubmVjdGVkLgoKIyBGbG93R3JhcGhJbnN0cnVtZW50OgojIEl0IGhhcyBVbml0 cyBhbmQgQ2FibGVzLiBJdHMgYWRkQ2FibGUgbWV0aG9kIGlzIHJlc3BvbnNpYmxlIGZvcgpjb3Jy ZWN0IGNvbm5lY3Rpb25zLgppbnQgYWRkQ2FibGUoUG9ydCBpbnB1dCwgUG9ydCBvdXRwdXQpOwpy ZXR1cm5zIE9VVF9UT19PVVQgb3Igc2ltaWxhciBzdGF0aWMgaW50IHZhbHVlcyBhY2NvcmRpbmcg dG8gZmFsc2UKY29ubmVjdGlvbnMsIENPTk5FQ1RFRCBmb3IgY29ycmVjdCBvbmVzIGV0Yy4KIyBh bmQgZmluYWxseSB0aGUgaGFyZGVzdCBtZXRob2Q6IHB1YmxpYyBTdHJpbmcgZ2VuZXJhdGVJbnN0 cnVtZW50KCkKd2hpY2gsIGlmIEkgdW5kZXJzdG9vZCBjb3JyZWN0bHksIGdlbmVyYXRlcyB0aGUg Q3NvdW5kIGluc3RydW1lbnQgY29kZSEKCiMgVGhpcyBpcyB0aGUgZHJhZnQgc3RydWN0dXJlIEkg dGhpbmsgdG8gYnVpbGQuIERvIHlvdSBoYXZlIGFueQpvYmplY3Rpb25zLCBvciBwcm9wZXJ0aWVz IHdhbnQgdG8gYWRkLgojIG5leHQgSSdsbCBzZW5kIGEgbWFpbCBhYm91dCB0aGUgY2xhc3NlcyBv ZiBncmFwaGljYWwgaW50ZXJmYWNlLgoKLXVndXItCg== |