RC tomorrow

View: New views
20 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 - 3 | Next >

Re: RC tomorrow: [commit?] MixedMessage

by Julian Rohrhuber :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Ron,

as discussed at the symposium, we should add a MixedMethod
implementation. IMHO this should be part of the RC:

ok to commit?


MixedMessage {
        var <>messages;
        *new { |messages|
                ^super.newCopyArgs(messages)
        }

        perform { |receiver ... args|
                ^messages.collect { |each|
                        receiver.performList(each, args)
                }
        }


}


(sorry, just needed a break from a deadline tonight..)
adc, jrh
--





.

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow: [commit?] MixedMessage

by ronald kuivila :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Actually, I missed this discussion (probably fielding yet another  
phone call).
Seems fine to me as it has no impact on any other code (yet).  Could  
you post an example
of where you need it?

RJK

On Apr 21, 2009, at 6:28 PM, Julian Rohrhuber wrote:

> Hi Ron,
>
> as discussed at the symposium, we should add a MixedMethod  
> implementation. IMHO this should be part of the RC:
>
> ok to commit?
>
>
> MixedMessage {
> var <>messages;
> *new { |messages|
> ^super.newCopyArgs(messages)
> }
>
> perform { |receiver ... args|
> ^messages.collect { |each|
> receiver.performList(each, args)
> }
> }
>
>
> }
>
>
> (sorry, just needed a break from a deadline tonight..)
> adc, jrh
> --
>
>
>
>
>
> .
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow: [commit?] MixedMessage

by Alberto de Campo-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

At 20:06 -0400 4/21/09, ronald kuivila wrote:
>Actually, I missed this discussion (probably fielding yet another phone call).
>Seems fine to me as it has no impact on any other code (yet).  Could
>you post an example
>of where you need it?

Well, it comes in handy mainly in ambigous situations.
Seems there should also be a MissedMessage, no?

best, a

>RJK
>
>On Apr 21, 2009, at 6:28 PM, Julian Rohrhuber wrote:
>
>>Hi Ron,
>>
>>as discussed at the symposium, we should add a MixedMethod
>>implementation. IMHO this should be part of the RC:
>>
>>ok to commit?
>>
>>
>>MixedMessage {
>> var <>messages;
>> *new { |messages|
>> ^super.newCopyArgs(messages)
>> }
>>
>> perform { |receiver ... args|
>> ^messages.collect { |each|
>> receiver.performList(each, args)
>> }
>> }
>>
>>
>>}
>>
>>
>>(sorry, just needed a break from a deadline tonight..)
>>adc, jrh
>>--
>>
>>
>>
>>
>>
>>.
>>
>>_______________________________________________
>>sc-dev mailing list
>>
>>info (subscription, etc.):
>>http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>
>
>_______________________________________________
>sc-dev mailing list
>
>info (subscription, etc.):
>http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/


--
--
Alberto de Campo
Bergstrasse 59/33
A-8020 Graz, Austria
e-mail : adc@...
--

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow

by felix-38 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


obviously anything that is considered generally useful I would be more than happy to move to common.

KeyCodeResponder seems to me generally useful and in standard sc style with other responder classes.

I leave it up to others to discuss, since its based on what was found useful and general.

and then the rest of my crap I'll happily haul off.

also of course anything that's put onto Common is more easily maintained and improved as Jan did below.



jan - the bw. compat way would be to add the command at the end.

I don't know what most people's usage is or how much would be broke. 
its an annoying thing to break though ... somebody updates ... all the keys are broke.
its a special kind of annoyance.  its like your own hands are what get frustrated and that makes you feel helpless.  it doesn't work anymore !  trash trash trash.

if using keyword arguments then you don't have to worry about the order anyway.

good news that you got the command-key working though!


On Tue, Apr 21, 2009 at 9:53 PM, Jan T <sc3@...> wrote:
I would also vote for keeping crucial in for 3.3 . And I won't move the
responder files for now...
I changed KeyCodeResponder and UnicodeResponder, so that they k now about
command modifiers. But in order to make that modifiers more accessible we
would need to change the synthax for register.
from
register( unicode, shift, caps, option, control, function )
to
register( unicode, shift, caps, option, control, command,  function )
But i wouldn't do that for 3.3.

At the moment you can do:

k.registerKeycode(KeyCodeResponder.commandModifier , 123 , {
       "command <-".postln;
});

j

On Tue, 21 Apr 2009 21:50:37 +0200, felix <felix@...>
wrote:
> ok, cool.  agreed.
>
> I'm sure those methods got around.  they have been due for transfer or
> being
> eliminated for quite a while.
>
> can't remember what they are or how many there are.
> its more than just .debug
>
> I'm sure its all no more than a days work for me.
>
> main problem is that my sc is out of sync.  I tried to sync it and it
> broke.
>
> there was an intensive work schedule from me many months ago and I
> couldn't
> test it and check it all in,
>
>
>
>
> On Tue, Apr 21, 2009 at 9:06 PM, Dan Stowell <danstowell@...>
wrote:
>
>> 2009/4/21, Josh Parmenter <josh@...>:
>> > I am of the opinion that you only do an RC if you really mean RC. So,
> I
>> > don't think we should plan on another one until it becomes obvious one
> is
>> > necessary.
>>
>> I agree
>>
>>
>> >  It won't be until tonight that I could actually get to building
> anyways
>> as
>> > my day has been as swamped as my last night.
>> >
>> >  How about this:
>> >
>> >  3.3 with Crucial
>> >  3.4 work could be towards efficiency and leaning things up over the
> next
>> > few months,
>>
>
> yes, I would say that there are other things in the SC common that are
> vestigal and better moved into a quark.  a clean common would be useful.


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/


Re: RC tomorrow: [commit?] MixedMessage

by nescivi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Tuesday 21 April 2009 20:59:32 Alberto de Campo wrote:
> At 20:06 -0400 4/21/09, ronald kuivila wrote:
> >Actually, I missed this discussion (probably fielding yet another phone
> > call). Seems fine to me as it has no impact on any other code (yet).
> > Could you post an example
> >of where you need it?
>
> Well, it comes in handy mainly in ambigous situations.
> Seems there should also be a MissedMessage, no?

definately.

Are you sure the MixedMessage implementation is allright?
I think it should be this:

MixedMessage {
var <>messages,<>confusion;

*new { |messages,confusion|
                ^super.newCopyArgs(messages,confusion)
}

perform { |receiver ... args|
                ^messages.collect { |each|
                if ( confusion.coin ){
                        receiver.performList(each, args)
                }
        }
}


> best, a
>
> >RJK
> >
> >On Apr 21, 2009, at 6:28 PM, Julian Rohrhuber wrote:
> >>Hi Ron,
> >>
> >>as discussed at the symposium, we should add a MixedMethod
> >>implementation. IMHO this should be part of the RC:
> >>
> >>ok to commit?
> >>
> >>
> >>MixedMessage {
> >> var <>messages;
> >> *new { |messages|
> >> ^super.newCopyArgs(messages)
> >> }
> >>
> >> perform { |receiver ... args|
> >> ^messages.collect { |each|
> >> receiver.performList(each, args)
> >> }
> >> }
> >>
> >>
> >>}
> >>
> >>
> >>(sorry, just needed a break from a deadline tonight..)
> >>adc, jrh
> >>--

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow: [commit?] MixedMessage

by nescivi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Tuesday 21 April 2009 21:17:07 nescivi wrote:

> On Tuesday 21 April 2009 20:59:32 Alberto de Campo wrote:
> > At 20:06 -0400 4/21/09, ronald kuivila wrote:
> > >Actually, I missed this discussion (probably fielding yet another phone
> > > call). Seems fine to me as it has no impact on any other code (yet).
> > > Could you post an example
> > >of where you need it?
> >
> > Well, it comes in handy mainly in ambigous situations.
> > Seems there should also be a MissedMessage, no?
>
> definately.
>
> Are you sure the MixedMessage implementation is allright?
> I think it should be this:
>
> MixedMessage {
> var <>messages,<>confusion;
>
> *new { |messages,confusion|
> ^super.newCopyArgs(messages,confusion)
> }
>
> perform { |receiver ... args|
> ^messages.collect { |each|

> if ( confusion.coin ){

Sorry that should read:
  if ( confusion.coin.not ){

> receiver.performList(each, args)
> }
> }
> }
>
> > best, a
> >
> > >RJK
> > >
> > >On Apr 21, 2009, at 6:28 PM, Julian Rohrhuber wrote:
> > >>Hi Ron,
> > >>
> > >>as discussed at the symposium, we should add a MixedMethod
> > >>implementation. IMHO this should be part of the RC:
> > >>
> > >>ok to commit?
> > >>
> > >>
> > >>MixedMessage {
> > >> var <>messages;
> > >> *new { |messages|
> > >> ^super.newCopyArgs(messages)
> > >> }
> > >>
> > >> perform { |receiver ... args|
> > >> ^messages.collect { |each|
> > >> receiver.performList(each, args)
> > >> }
> > >> }
> > >>
> > >>
> > >>}
> > >>
> > >>
> > >>(sorry, just needed a break from a deadline tonight..)
> > >>adc, jrh
> > >>--
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.):
> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml archive:
> http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/



_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow: [commit?] MixedMessage

by Alberto de Campo-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>On Tuesday 21 April 2009 21:17:07 nescivi wrote:
>>  On Tuesday 21 April 2009 20:59:32 Alberto de Campo wrote:
>>  > At 20:06 -0400 4/21/09, ronald kuivila wrote:
>>  > >Actually, I missed this discussion (probably fielding yet another phone
>>  > > call). Seems fine to me as it has no impact on any other code (yet).
>>  > > Could you post an example
>>  > >of where you need it?
>>  >
>>  > Well, it comes in handy mainly in ambigous situations.
>>  > Seems there should also be a MissedMessage, no?
>>
>>  definately.
>>
>>  Are you sure the MixedMessage implementation is allright?
>>  I think it should be this:
>>
>>  MixedMessage {
>>  var <>messages,<>confusion;
>>
>>  *new { |messages,confusion|
>> ^super.newCopyArgs(messages,confusion)
>>  }
>>
>>  perform { |receiver ... args|
>> ^messages.collect { |each|
>
>> if ( confusion.coin ){
>
>Sorry that should read:
>   if ( confusion.coin.not ){

yes, much clearer that way.
best, a

>  > receiver.performList(each, args)
>> }
>> }
>>  }
>>
>>  > best, a
>>  >
>>  > >RJK
>>  > >
>>  > >On Apr 21, 2009, at 6:28 PM, Julian Rohrhuber wrote:
>>  > >>Hi Ron,
>>  > >>
>>  > >>as discussed at the symposium, we should add a MixedMethod
>>  > >>implementation. IMHO this should be part of the RC:
>>  > >>
>>  > >>ok to commit?
>>  > >>
>>  > >>
>>  > >>MixedMessage {
>>  > >> var <>messages;
>>  > >> *new { |messages|
>>  > >> ^super.newCopyArgs(messages)
>>  > >> }
>>  > >>
>>  > >> perform { |receiver ... args|
>>  > >> ^messages.collect { |each|
>>  > >> receiver.performList(each, args)
>>  > >> }
>>  > >> }
>>  > >>
>>  > >>
>>  > >>}
>>  > >>
>>  > >>
>>  > >>(sorry, just needed a break from a deadline tonight..)
>>  > >>adc, jrh
>>  > >>--
>>
>>  _______________________________________________
>>  sc-dev mailing list
>>
>>  info (subscription, etc.):
>>  http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml archive:
>>  http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>  search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>
>
>
>_______________________________________________
>sc-dev mailing list
>
>info (subscription, etc.):
>http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/


--
--
Alberto de Campo
Bergstrasse 59/33
A-8020 Graz, Austria
e-mail : adc@...
--

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow: [commit?] MixedMessage

by Josh Parmenter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

please commit what will be committed.

Best,

Josh

On Apr 21, 2009, at 6:59 PM, Alberto de Campo wrote:

>> On Tuesday 21 April 2009 21:17:07 nescivi wrote:
>>> On Tuesday 21 April 2009 20:59:32 Alberto de Campo wrote:
>>> > At 20:06 -0400 4/21/09, ronald kuivila wrote:
>>> > >Actually, I missed this discussion (probably fielding yet  
>>> another phone
>>> > > call). Seems fine to me as it has no impact on any other code  
>>> (yet).
>>> > > Could you post an example
>>> > >of where you need it?
>>> >
>>> > Well, it comes in handy mainly in ambigous situations.
>>> > Seems there should also be a MissedMessage, no?
>>>
>>> definately.
>>>
>>> Are you sure the MixedMessage implementation is allright?
>>> I think it should be this:
>>>
>>> MixedMessage {
>>> var <>messages,<>confusion;
>>>
>>> *new { |messages,confusion|
>>> ^super.newCopyArgs(messages,confusion)
>>> }
>>>
>>> perform { |receiver ... args|
>>> ^messages.collect { |each|
>>
>>> if ( confusion.coin ){
>>
>> Sorry that should read:
>> if ( confusion.coin.not ){
>
> yes, much clearer that way.
> best, a
>
>> > receiver.performList(each, args)
>>> }
>>> }
>>> }
>>>
>>> > best, a
>>> >
>>> > >RJK
>>> > >
>>> > >On Apr 21, 2009, at 6:28 PM, Julian Rohrhuber wrote:
>>> > >>Hi Ron,
>>> > >>
>>> > >>as discussed at the symposium, we should add a MixedMethod
>>> > >>implementation. IMHO this should be part of the RC:
>>> > >>
>>> > >>ok to commit?
>>> > >>
>>> > >>
>>> > >>MixedMessage {
>>> > >> var <>messages;
>>> > >> *new { |messages|
>>> > >> ^super.newCopyArgs(messages)
>>> > >> }
>>> > >>
>>> > >> perform { |receiver ... args|
>>> > >> ^messages.collect { |each|
>>> > >> receiver.performList(each, args)
>>> > >> }
>>> > >> }
>>> > >>
>>> > >>
>>> > >>}
>>> > >>
>>> > >>
>>> > >>(sorry, just needed a break from a deadline tonight..)
>>> > >>adc, jrh
>>> > >>--
>>>
>>> _______________________________________________
>>> sc-dev mailing list
>>>
>>> info (subscription, etc.):
>>> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml archive:
>>> http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>>
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>
>
> --
> --
> Alberto de Campo
> Bergstrasse 59/33
> A-8020 Graz, Austria
> e-mail : adc@...
> --
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow: [commit?] MixedMessage

by Josh Parmenter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Is this going to be committed?

Best,

Josh

On Apr 21, 2009, at 6:59 PM, Alberto de Campo wrote:

>> On Tuesday 21 April 2009 21:17:07 nescivi wrote:
>>> On Tuesday 21 April 2009 20:59:32 Alberto de Campo wrote:
>>> > At 20:06 -0400 4/21/09, ronald kuivila wrote:
>>> > >Actually, I missed this discussion (probably fielding yet  
>>> another phone
>>> > > call). Seems fine to me as it has no impact on any other code  
>>> (yet).
>>> > > Could you post an example
>>> > >of where you need it?
>>> >
>>> > Well, it comes in handy mainly in ambigous situations.
>>> > Seems there should also be a MissedMessage, no?
>>>
>>> definately.
>>>
>>> Are you sure the MixedMessage implementation is allright?
>>> I think it should be this:
>>>
>>> MixedMessage {
>>> var <>messages,<>confusion;
>>>
>>> *new { |messages,confusion|
>>> ^super.newCopyArgs(messages,confusion)
>>> }
>>>
>>> perform { |receiver ... args|
>>> ^messages.collect { |each|
>>
>>> if ( confusion.coin ){
>>
>> Sorry that should read:
>> if ( confusion.coin.not ){
>
> yes, much clearer that way.
> best, a
>
>> > receiver.performList(each, args)
>>> }
>>> }
>>> }
>>>
>>> > best, a
>>> >
>>> > >RJK
>>> > >
>>> > >On Apr 21, 2009, at 6:28 PM, Julian Rohrhuber wrote:
>>> > >>Hi Ron,
>>> > >>
>>> > >>as discussed at the symposium, we should add a MixedMethod
>>> > >>implementation. IMHO this should be part of the RC:
>>> > >>
>>> > >>ok to commit?
>>> > >>
>>> > >>
>>> > >>MixedMessage {
>>> > >> var <>messages;
>>> > >> *new { |messages|
>>> > >> ^super.newCopyArgs(messages)
>>> > >> }
>>> > >>
>>> > >> perform { |receiver ... args|
>>> > >> ^messages.collect { |each|
>>> > >> receiver.performList(each, args)
>>> > >> }
>>> > >> }
>>> > >>
>>> > >>
>>> > >>}
>>> > >>
>>> > >>
>>> > >>(sorry, just needed a break from a deadline tonight..)
>>> > >>adc, jrh
>>> > >>--
>>>
>>> _______________________________________________
>>> sc-dev mailing list
>>>
>>> info (subscription, etc.):
>>> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml archive:
>>> http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>>
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>
>
> --
> --
> Alberto de Campo
> Bergstrasse 59/33
> A-8020 Graz, Austria
> e-mail : adc@...
> --
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow: [commit?] MixedMessage

by Julian Rohrhuber :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

unmixed message:
no, of course not!
sorry for the noise..

>Is this going to be committed?
>
>Best,
>
>Josh
>
>On Apr 21, 2009, at 6:59 PM, Alberto de Campo wrote:
>
>>>On Tuesday 21 April 2009 21:17:07 nescivi wrote:
>>>>On Tuesday 21 April 2009 20:59:32 Alberto de Campo wrote:
>>>>>  At 20:06 -0400 4/21/09, ronald kuivila wrote:
>>>>>  >Actually, I missed this discussion (probably fielding yet another phone
>>>>>  > call). Seems fine to me as it has no impact on any other code (yet).
>>>>>  > Could you post an example
>>>>>  >of where you need it?
>>>>>
>>>>>  Well, it comes in handy mainly in ambigous situations.
>>>>>  Seems there should also be a MissedMessage, no?
>>>>
>>>>definately.
>>>>
>>>>Are you sure the MixedMessage implementation is allright?
>>>>I think it should be this:
>>>>
>>>>MixedMessage {
>>>>var <>messages,<>confusion;
>>>>
>>>>*new { |messages,confusion|
>>>> ^super.newCopyArgs(messages,confusion)
>>>>}
>>>>
>>>>perform { |receiver ... args|
>>>> ^messages.collect { |each|
>>>
>>>> if ( confusion.coin ){
>>>
>>>Sorry that should read:
>>> if ( confusion.coin.not ){
>>
>>yes, much clearer that way.
>>best, a
>>
>>>  > receiver.performList(each, args)
>>>> }
>>>> }
>>>>}
>>>>
>>>>>  best, a
>>>>>
>>>>>  >RJK
>>>>>  >
>>>>>  >On Apr 21, 2009, at 6:28 PM, Julian Rohrhuber wrote:
>>>>>  >>Hi Ron,
>>>>>  >>
>>>>>  >>as discussed at the symposium, we should add a MixedMethod
>>>>>  >>implementation. IMHO this should be part of the RC:
>>>>>  >>
>>>>>  >>ok to commit?
>>>>>  >>
>>>>>  >>
>>>>>  >>MixedMessage {
>>>>>  >> var <>messages;
>>>>>  >> *new { |messages|
>>>>>  >> ^super.newCopyArgs(messages)
>>>>>  >> }
>>>>>  >>
>>>>>  >> perform { |receiver ... args|
>>>>>  >> ^messages.collect { |each|
>>>>>  >> receiver.performList(each, args)
>>>>>  >> }
>>>>>  >> }
>>>>>  >>
>>>>>  >>
>>>>>  >>}
>>>>>  >>
>>>>>  >>
>>>>>  >>(sorry, just needed a break from a deadline tonight..)
>>>>>  >>adc, jrh
>>>>>  >>--
>>>>
>>>>_______________________________________________
>>>>sc-dev mailing list
>>>>
>>>>info (subscription, etc.):
>>>>http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml archive:
>>>>http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>>>search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>>
>>>
>>>
>>>_______________________________________________
>>>sc-dev mailing list
>>>
>>>info (subscription, etc.):
>>>http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>>archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>>search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>>
>>--
>>--
>>Alberto de Campo
>>Bergstrasse 59/33
>>A-8020 Graz, Austria
>>e-mail : adc@...
>>--
>>
>>_______________________________________________
>>sc-dev mailing list
>>
>>info (subscription, etc.):
>>http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>
>******************************************
>/* Joshua D. Parmenter
>http://www.realizedsound.net/josh/
>
>"Every composer - at all times and in all cases - gives his own
>interpretation of how modern society is structured: whether actively
>or passively, consciously or unconsciously, he makes choices in this
>regard. He may be conservative or he may subject himself to
>continual renewal; or he may strive for a revolutionary, historical
>or social palingenesis." - Luigi Nono
>*/
>
>
>_______________________________________________
>sc-dev mailing list
>
>info (subscription, etc.):
>http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/


--





.

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow

by Click Nilson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Josh, I think you're clear to proceed with RC, many thanks for all  
your hard work, past, present and future.

We're agreed we'll sort out crucial lib later on.

Hopefully one week with RC for stability, then official 3.3 next week.

best,
N



_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow

by Josh Parmenter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

HAHAHA...

I'm soooo tired.

Packaging on my bus ride this AM.

Josh

On Apr 22, 2009, at 3:49 AM, Click Nilson wrote:

> Josh, I think you're clear to proceed with RC, many thanks for all  
> your hard work, past, present and future.
>
> We're agreed we'll sort out crucial lib later on.
>
> Hopefully one week with RC for stability, then official 3.3 next week.
>
> best,
> N
>
>
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow

by Josh Parmenter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

OK . rev 9101 is the RC and hopefully 3.3!

Josh

On Apr 22, 2009, at 3:49 AM, Click Nilson wrote:

> Josh, I think you're clear to proceed with RC, many thanks for all  
> your hard work, past, present and future.
>
> We're agreed we'll sort out crucial lib later on.
>
> Hopefully one week with RC for stability, then official 3.3 next week.
>
> best,
> N
>
>
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow

by Dan Stowell :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

lol

Yes indeed thanks for all the packaging work Josh!

Dan

2009/4/22 Josh Parmenter <josh@...>:

> HAHAHA...
>
> I'm soooo tired.
>
> Packaging on my bus ride this AM.
>
> Josh
>
> On Apr 22, 2009, at 3:49 AM, Click Nilson wrote:
>
>> Josh, I think you're clear to proceed with RC, many thanks for all your
>> hard work, past, present and future.
>>
>> We're agreed we'll sort out crucial lib later on.
>>
>> Hopefully one week with RC for stability, then official 3.3 next week.
>>
>> best,

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow

by Josh Parmenter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Was about to package, and realized I don't have the latest SwingOSC  
yet - sciss, do you have a link?

Josh

On Apr 21, 2009, at 1:29 PM, Sciss wrote:

> is there going to be a With-Extras version? if so, i would like to  
> have the latest SwingOSC included. shall i send you a binary?
>
> BTW: from the supercollider.sf.net site, it's not possible to find  
> the 3.3 RC downloads....
>
> ciao, -sciss-
>
>
> Am 21.04.2009 um 22:25 schrieb Josh Parmenter:
>
>> OK - good, so it sounds like we are RC ready... I'll start  
>> packaging in about an hour unless I hear otherwise.
>>
>> Best,
>>
>> Josh
>>
>> On Apr 21, 2009, at 12:53 PM, Jan T wrote:
>>
>>> I would also vote for keeping crucial in for 3.3 . And I won't  
>>> move the
>>> responder files for now...
>>> I changed KeyCodeResponder and UnicodeResponder, so that they k  
>>> now about
>>> command modifiers. But in order to make that modifiers more  
>>> accessible we
>>> would need to change the synthax for register.
>>> from
>>> register( unicode, shift, caps, option, control, function )
>>> to
>>> register( unicode, shift, caps, option, control, command,  
>>> function )
>>> But i wouldn't do that for 3.3.
>>>
>>> At the moment you can do:
>>>
>>> k.registerKeycode(KeyCodeResponder.commandModifier , 123 , {
>>> "command <-".postln;
>>> });
>>>
>>> j
>>>
>>> On Tue, 21 Apr 2009 21:50:37 +0200, felix <felix@crucial-
>>> systems.com>
>>> wrote:
>>>> ok, cool.  agreed.
>>>>
>>>> I'm sure those methods got around.  they have been due for  
>>>> transfer or
>>>> being
>>>> eliminated for quite a while.
>>>>
>>>> can't remember what they are or how many there are.
>>>> its more than just .debug
>>>>
>>>> I'm sure its all no more than a days work for me.
>>>>
>>>> main problem is that my sc is out of sync.  I tried to sync it  
>>>> and it
>>>> broke.
>>>>
>>>> there was an intensive work schedule from me many months ago and I
>>>> couldn't
>>>> test it and check it all in,
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Apr 21, 2009 at 9:06 PM, Dan Stowell <danstowell@...>
>>> wrote:
>>>>
>>>>> 2009/4/21, Josh Parmenter <josh@...>:
>>>>>> I am of the opinion that you only do an RC if you really mean  
>>>>>> RC. So,
>>>> I
>>>>>> don't think we should plan on another one until it becomes  
>>>>>> obvious one
>>>> is
>>>>>> necessary.
>>>>>
>>>>> I agree
>>>>>
>>>>>
>>>>>> It won't be until tonight that I could actually get to building
>>>> anyways
>>>>> as
>>>>>> my day has been as swamped as my last night.
>>>>>>
>>>>>> How about this:
>>>>>>
>>>>>> 3.3 with Crucial
>>>>>> 3.4 work could be towards efficiency and leaning things up over  
>>>>>> the
>>>> next
>>>>>> few months,
>>>>>
>>>>
>>>> yes, I would say that there are other things in the SC common  
>>>> that are
>>>> vestigal and better moved into a quark.  a clean common would be  
>>>> useful.
>>>
>>>
>>> _______________________________________________
>>> sc-dev mailing list
>>>
>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>> ******************************************
>> /* Joshua D. Parmenter
>> http://www.realizedsound.net/josh/
>>
>> “Every composer – at all times and in all cases – gives his own  
>> interpretation of how modern society is structured: whether  
>> actively or passively, consciously or unconsciously, he makes  
>> choices in this regard. He may be conservative or he may subject  
>> himself to continual renewal; or he may strive for a revolutionary,  
>> historical or social palingenesis." - Luigi Nono
>> */
>>
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow

by Sciss-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

i'm sorry i was occupied all day; i'm trying to send one within the  
next two hours...

i know i'm the last minute, but if these lines could be added to  
Server:meter, it would be working with SwingOSC...

        meter {
                var window, inmeters, outmeters, inresp, outresp, insynth,  
outsynth, func;
                var numIns, numOuts;
                var view, viewWidth, meterWidth = 15, gapWidth = 4;
                var updateFreq = 10, dBLow = -80;
                var numRMSSamps, numRMSSampsRecip;
               
                if( GUI.id == \swing and: { \JSCPeakMeter.asClass.notNil }, {
                        JSCPeakMeter.meterServer( this );
                        ^this;
                });

... what worries me is that this code is in SCLevelIndicator.sc which  
is in an osx folder, so i guess Server:meter doesn't exist on  
Linux...? Could that be moved then to a platform neutral file, like  
Common/GUI/PlusGUI/Control/plusMeter.sc or so?

ciao, -sciss-







Am 22.04.2009 um 16:55 schrieb Josh Parmenter:

> Was about to package, and realized I don't have the latest SwingOSC  
> yet - sciss, do you have a link?
>
> Josh
>
> On Apr 21, 2009, at 1:29 PM, Sciss wrote:
>
>> is there going to be a With-Extras version? if so, i would like to  
>> have the latest SwingOSC included. shall i send you a binary?
>>
>> BTW: from the supercollider.sf.net site, it's not possible to find  
>> the 3.3 RC downloads....
>>
>> ciao, -sciss-
>>
>>
>> Am 21.04.2009 um 22:25 schrieb Josh Parmenter:
>>
>>> OK - good, so it sounds like we are RC ready... I'll start  
>>> packaging in about an hour unless I hear otherwise.
>>>
>>> Best,
>>>
>>> Josh
>>>
>>> On Apr 21, 2009, at 12:53 PM, Jan T wrote:
>>>
>>>> I would also vote for keeping crucial in for 3.3 . And I won't  
>>>> move the
>>>> responder files for now...
>>>> I changed KeyCodeResponder and UnicodeResponder, so that they k  
>>>> now about
>>>> command modifiers. But in order to make that modifiers more  
>>>> accessible we
>>>> would need to change the synthax for register.
>>>> from
>>>> register( unicode, shift, caps, option, control, function )
>>>> to
>>>> register( unicode, shift, caps, option, control, command,  
>>>> function )
>>>> But i wouldn't do that for 3.3.
>>>>
>>>> At the moment you can do:
>>>>
>>>> k.registerKeycode(KeyCodeResponder.commandModifier , 123 , {
>>>> "command <-".postln;
>>>> });
>>>>
>>>> j
>>>>
>>>> On Tue, 21 Apr 2009 21:50:37 +0200, felix <felix@crucial-
>>>> systems.com>
>>>> wrote:
>>>>> ok, cool.  agreed.
>>>>>
>>>>> I'm sure those methods got around.  they have been due for  
>>>>> transfer or
>>>>> being
>>>>> eliminated for quite a while.
>>>>>
>>>>> can't remember what they are or how many there are.
>>>>> its more than just .debug
>>>>>
>>>>> I'm sure its all no more than a days work for me.
>>>>>
>>>>> main problem is that my sc is out of sync.  I tried to sync it  
>>>>> and it
>>>>> broke.
>>>>>
>>>>> there was an intensive work schedule from me many months ago and I
>>>>> couldn't
>>>>> test it and check it all in,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 21, 2009 at 9:06 PM, Dan Stowell  
>>>>> <danstowell@...>
>>>> wrote:
>>>>>
>>>>>> 2009/4/21, Josh Parmenter <josh@...>:
>>>>>>> I am of the opinion that you only do an RC if you really mean  
>>>>>>> RC. So,
>>>>> I
>>>>>>> don't think we should plan on another one until it becomes  
>>>>>>> obvious one
>>>>> is
>>>>>>> necessary.
>>>>>>
>>>>>> I agree
>>>>>>
>>>>>>
>>>>>>> It won't be until tonight that I could actually get to building
>>>>> anyways
>>>>>> as
>>>>>>> my day has been as swamped as my last night.
>>>>>>>
>>>>>>> How about this:
>>>>>>>
>>>>>>> 3.3 with Crucial
>>>>>>> 3.4 work could be towards efficiency and leaning things up  
>>>>>>> over the
>>>>> next
>>>>>>> few months,
>>>>>>
>>>>>
>>>>> yes, I would say that there are other things in the SC common  
>>>>> that are
>>>>> vestigal and better moved into a quark.  a clean common would  
>>>>> be useful.
>>>>
>>>>
>>>> _______________________________________________
>>>> sc-dev mailing list
>>>>
>>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/ 
>>>> sc_mailing_lists.shtml
>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>>
>>> ******************************************
>>> /* Joshua D. Parmenter
>>> http://www.realizedsound.net/josh/
>>>
>>> “Every composer – at all times and in all cases – gives his own  
>>> interpretation of how modern society is structured: whether  
>>> actively or passively, consciously or unconsciously, he makes  
>>> choices in this regard. He may be conservative or he may subject  
>>> himself to continual renewal; or he may strive for a  
>>> revolutionary, historical or social palingenesis." - Luigi Nono
>>> */
>>>
>>>
>>> _______________________________________________
>>> sc-dev mailing list
>>>
>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/ 
>>> sc_mailing_lists.shtml
>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/ 
>> sc_mailing_lists.shtml
>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>
> ******************************************
> /* Joshua D. Parmenter
> http://www.realizedsound.net/josh/
>
> “Every composer – at all times and in all cases – gives his own  
> interpretation of how modern society is structured: whether  
> actively or passively, consciously or unconsciously, he makes  
> choices in this regard. He may be conservative or he may subject  
> himself to continual renewal; or he may strive for a revolutionary,  
> historical or social palingenesis." - Luigi Nono
> */
>
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/ 
> sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/


Bild 4.png (100 bytes) Download Attachment
Bild 4.png (132K) Download Attachment

Re: RC tomorrow

by Josh Parmenter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Scott - any feeling about this? I haven't dealt with the Meter stuff  
that much,

Sciss - no problem, my day at work is more open, so once it is ready  
and this is figured out, we're good!

Josh

On Apr 22, 2009, at 10:51 AM, Sciss wrote:

> i'm sorry i was occupied all day; i'm trying to send one within the  
> next two hours...
>
> i know i'm the last minute, but if these lines could be added to  
> Server:meter, it would be working with SwingOSC...
>
> meter {
> var window, inmeters, outmeters, inresp, outresp, insynth,  
> outsynth, func;
> var numIns, numOuts;
> var view, viewWidth, meterWidth = 15, gapWidth = 4;
> var updateFreq = 10, dBLow = -80;
> var numRMSSamps, numRMSSampsRecip;
>
> if( GUI.id == \swing and: { \JSCPeakMeter.asClass.notNil }, {
> JSCPeakMeter.meterServer( this );
> ^this;
> });
>
> ... what worries me is that this code is in SCLevelIndicator.sc  
> which is in an osx folder, so i guess Server:meter doesn't exist on  
> Linux...? Could that be moved then to a platform neutral file, like  
> Common/GUI/PlusGUI/Control/plusMeter.sc or so?
>
> ciao, -sciss-
>
> <Bild 4.png>
>
>
> Am 22.04.2009 um 16:55 schrieb Josh Parmenter:
>
>> Was about to package, and realized I don't have the latest SwingOSC  
>> yet - sciss, do you have a link?
>>
>> Josh
>>
>> On Apr 21, 2009, at 1:29 PM, Sciss wrote:
>>
>>> is there going to be a With-Extras version? if so, i would like to  
>>> have the latest SwingOSC included. shall i send you a binary?
>>>
>>> BTW: from the supercollider.sf.net site, it's not possible to find  
>>> the 3.3 RC downloads....
>>>
>>> ciao, -sciss-
>>>
>>>
>>> Am 21.04.2009 um 22:25 schrieb Josh Parmenter:
>>>
>>>> OK - good, so it sounds like we are RC ready... I'll start  
>>>> packaging in about an hour unless I hear otherwise.
>>>>
>>>> Best,
>>>>
>>>> Josh
>>>>
>>>> On Apr 21, 2009, at 12:53 PM, Jan T wrote:
>>>>
>>>>> I would also vote for keeping crucial in for 3.3 . And I won't  
>>>>> move the
>>>>> responder files for now...
>>>>> I changed KeyCodeResponder and UnicodeResponder, so that they k  
>>>>> now about
>>>>> command modifiers. But in order to make that modifiers more  
>>>>> accessible we
>>>>> would need to change the synthax for register.
>>>>> from
>>>>> register( unicode, shift, caps, option, control, function )
>>>>> to
>>>>> register( unicode, shift, caps, option, control, command,  
>>>>> function )
>>>>> But i wouldn't do that for 3.3.
>>>>>
>>>>> At the moment you can do:
>>>>>
>>>>> k.registerKeycode(KeyCodeResponder.commandModifier , 123 , {
>>>>> "command <-".postln;
>>>>> });
>>>>>
>>>>> j
>>>>>
>>>>> On Tue, 21 Apr 2009 21:50:37 +0200, felix <felix@...
>>>>> >
>>>>> wrote:
>>>>>> ok, cool.  agreed.
>>>>>>
>>>>>> I'm sure those methods got around.  they have been due for  
>>>>>> transfer or
>>>>>> being
>>>>>> eliminated for quite a while.
>>>>>>
>>>>>> can't remember what they are or how many there are.
>>>>>> its more than just .debug
>>>>>>
>>>>>> I'm sure its all no more than a days work for me.
>>>>>>
>>>>>> main problem is that my sc is out of sync.  I tried to sync it  
>>>>>> and it
>>>>>> broke.
>>>>>>
>>>>>> there was an intensive work schedule from me many months ago  
>>>>>> and I
>>>>>> couldn't
>>>>>> test it and check it all in,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 21, 2009 at 9:06 PM, Dan Stowell <danstowell@...
>>>>>> >
>>>>> wrote:
>>>>>>
>>>>>>> 2009/4/21, Josh Parmenter <josh@...>:
>>>>>>>> I am of the opinion that you only do an RC if you really mean  
>>>>>>>> RC. So,
>>>>>> I
>>>>>>>> don't think we should plan on another one until it becomes  
>>>>>>>> obvious one
>>>>>> is
>>>>>>>> necessary.
>>>>>>>
>>>>>>> I agree
>>>>>>>
>>>>>>>
>>>>>>>> It won't be until tonight that I could actually get to building
>>>>>> anyways
>>>>>>> as
>>>>>>>> my day has been as swamped as my last night.
>>>>>>>>
>>>>>>>> How about this:
>>>>>>>>
>>>>>>>> 3.3 with Crucial
>>>>>>>> 3.4 work could be towards efficiency and leaning things up  
>>>>>>>> over the
>>>>>> next
>>>>>>>> few months,
>>>>>>>
>>>>>>
>>>>>> yes, I would say that there are other things in the SC common  
>>>>>> that are
>>>>>> vestigal and better moved into a quark.  a clean common would  
>>>>>> be useful.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sc-dev mailing list
>>>>>
>>>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>>>
>>>> ******************************************
>>>> /* Joshua D. Parmenter
>>>> http://www.realizedsound.net/josh/
>>>>
>>>> “Every composer – at all times and in all cases – gives his own  
>>>> interpretation of how modern society is structured: whether  
>>>> actively or passively, consciously or unconsciously, he makes  
>>>> choices in this regard. He may be conservative or he may subject  
>>>> himself to continual renewal; or he may strive for a  
>>>> revolutionary, historical or social palingenesis." - Luigi Nono
>>>> */
>>>>
>>>>
>>>> _______________________________________________
>>>> sc-dev mailing list
>>>>
>>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>>
>>>
>>> _______________________________________________
>>> sc-dev mailing list
>>>
>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>> ******************************************
>> /* Joshua D. Parmenter
>> http://www.realizedsound.net/josh/
>>
>> “Every composer – at all times and in all cases – gives his own  
>> interpretation of how modern society is structured: whether  
>> actively or passively, consciously or unconsciously, he makes  
>> choices in this regard. He may be conservative or he may subject  
>> himself to continual renewal; or he may strive for a revolutionary,  
>> historical or social palingenesis." - Luigi Nono
>> */
>>
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow

by nescivi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hiho,

On Wednesday 22 April 2009 13:51:30 Sciss wrote:

> i'm sorry i was occupied all day; i'm trying to send one within the
> next two hours...
>
> i know i'm the last minute, but if these lines could be added to
> Server:meter, it would be working with SwingOSC...
>
> meter {
> var window, inmeters, outmeters, inresp, outresp, insynth,
> outsynth, func;
> var numIns, numOuts;
> var view, viewWidth, meterWidth = 15, gapWidth = 4;
> var updateFreq = 10, dBLow = -80;
> var numRMSSamps, numRMSSampsRecip;
>
> if( GUI.id == \swing and: { \JSCPeakMeter.asClass.notNil }, {
> JSCPeakMeter.meterServer( this );
> ^this;
> });
>
> ... what worries me is that this code is in SCLevelIndicator.sc which
> is in an osx folder, so i guess Server:meter doesn't exist on
> Linux...? Could that be moved then to a platform neutral file, like
> Common/GUI/PlusGUI/Control/plusMeter.sc or so?

I guess, there should be a ViewRedirect then for the meter, and have a
platform independent method for the Server:meter method?

sincerely,
Marije

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow

by Sciss-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

the implementation is different, cocoa uses SCLevelIndicator, swing  
uses JSCPeakMeter; they are different things, so a common view  
redirector does not make sense in this moment. i think that for 3.3,  
the best is to branch off in Server:meter, and that's what i propose.  
This also avoid potential new problems in the last moment of getting  
the RC ready, as nothing regarding cocoa is changed, and swing didn't  
work before anyways.

ciao, -sciss-


Am 22.04.2009 um 20:26 schrieb nescivi:

> Hiho,
>
> On Wednesday 22 April 2009 13:51:30 Sciss wrote:
>> i'm sorry i was occupied all day; i'm trying to send one within the
>> next two hours...
>>
>> i know i'm the last minute, but if these lines could be added to
>> Server:meter, it would be working with SwingOSC...
>>
>> meter {
>> var window, inmeters, outmeters, inresp, outresp, insynth,
>> outsynth, func;
>> var numIns, numOuts;
>> var view, viewWidth, meterWidth = 15, gapWidth = 4;
>> var updateFreq = 10, dBLow = -80;
>> var numRMSSamps, numRMSSampsRecip;
>>
>> if( GUI.id == \swing and: { \JSCPeakMeter.asClass.notNil }, {
>> JSCPeakMeter.meterServer( this );
>> ^this;
>> });
>>
>> ... what worries me is that this code is in SCLevelIndicator.sc which
>> is in an osx folder, so i guess Server:meter doesn't exist on
>> Linux...? Could that be moved then to a platform neutral file, like
>> Common/GUI/PlusGUI/Control/plusMeter.sc or so?
>
> I guess, there should be a ViewRedirect then for the meter, and have a
> platform independent method for the Server:meter method?
>
> sincerely,
> Marije
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/ 
> sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: RC tomorrow

by Sciss-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

https://sourceforge.net/project/downloading.php?
group_id=155586&filename=SwingOSC-0.61RC_SVN176-090422.zip&a=43980979

but please let's wait for consense about adding to Server:meter ... i  
could also fix the mixing of cocoa and platform-indep. code in the  
current version of Server:meter

ciao, -sciss-


Am 22.04.2009 um 16:55 schrieb Josh Parmenter:

> Was about to package, and realized I don't have the latest SwingOSC  
> yet - sciss, do you have a link?
>
> Josh
>
> On Apr 21, 2009, at 1:29 PM, Sciss wrote:
>
>> is there going to be a With-Extras version? if so, i would like to  
>> have the latest SwingOSC included. shall i send you a binary?
>>
>> BTW: from the supercollider.sf.net site, it's not possible to find  
>> the 3.3 RC downloads....
>>
>> ciao, -sciss-
>>
>>
>> Am 21.04.2009 um 22:25 schrieb Josh Parmenter:
>>
>>> OK - good, so it sounds like we are RC ready... I'll start  
>>> packaging in about an hour unless I hear otherwise.
>>>
>>> Best,
>>>
>>> Josh
>>>
>>> On Apr 21, 2009, at 12:53 PM, Jan T wrote:
>>>
>>>> I would also vote for keeping crucial in for 3.3 . And I won't  
>>>> move the
>>>> responder files for now...
>>>> I changed KeyCodeResponder and UnicodeResponder, so that they k  
>>>> now about
>>>> command modifiers. But in order to make that modifiers more  
>>>> accessible we
>>>> would need to change the synthax for register.
>>>> from
>>>> register( unicode, shift, caps, option, control, function )
>>>> to
>>>> register( unicode, shift, caps, option, control, command,  
>>>> function )
>>>> But i wouldn't do that for 3.3.
>>>>
>>>> At the moment you can do:
>>>>
>>>> k.registerKeycode(KeyCodeResponder.commandModifier , 123 , {
>>>> "command <-".postln;
>>>> });
>>>>
>>>> j
>>>>
>>>> On Tue, 21 Apr 2009 21:50:37 +0200, felix <felix@crucial-
>>>> systems.com>
>>>> wrote:
>>>>> ok, cool.  agreed.
>>>>>
>>>>> I'm sure those methods got around.  they have been due for  
>>>>> transfer or
>>>>> being
>>>>> eliminated for quite a while.
>>>>>
>>>>> can't remember what they are or how many there are.
>>>>> its more than just .debug
>>>>>
>>>>> I'm sure its all no more than a days work for me.
>>>>>
>>>>> main problem is that my sc is out of sync.  I tried to sync it  
>>>>> and it
>>>>> broke.
>>>>>
>>>>> there was an intensive work schedule from me many months ago and I
>>>>> couldn't
>>>>> test it and check it all in,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 21, 2009 at 9:06 PM, Dan Stowell  
>>>>> <danstowell@...>
>>>> wrote:
>>>>>
>>>>>> 2009/4/21, Josh Parmenter <josh@...>:
>>>>>>> I am of the opinion that you only do an RC if you really mean  
>>>>>>> RC. So,
>>>>> I
>>>>>>> don't think we should plan on another one until it becomes  
>>>>>>> obvious one
>>>>> is
>>>>>>> necessary.
>>>>>>
>>>>>> I agree
>>>>>>
>>>>>>
>>>>>>> It won't be until tonight that I could actually get to building
>>>>> anyways
>>>>>> as
>>>>>>> my day has been as swamped as my last night.
>>>>>>>
>>>>>>> How about this:
>>>>>>>
>>>>>>> 3.3 with Crucial
>>>>>>> 3.4 work could be towards efficiency and leaning things up  
>>>>>>> over the
>>>>> next
>>>>>>> few months,
>>>>>>
>>>>>
>>>>> yes, I would say that there are other things in the SC common  
>>>>> that are
>>>>> vestigal and better moved into a quark.  a clean common would  
>>>>> be useful.
>>>>
>>>>
>>>> _______________________________________________
>>>> sc-dev mailing list
>>>>
>>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/ 
>>>> sc_mailing_lists.shtml
>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>>
>>> ******************************************
>>> /* Joshua D. Parmenter
>>> http://www.realizedsound.net/josh/
>>>
>>> “Every composer – at all times and in all cases – gives his own  
>>> interpretation of how modern society is structured: whether  
>>> actively or passively, consciously or unconsciously, he makes  
>>> choices in this regard. He may be conservative or he may subject  
>>> himself to continual renewal; or he may strive for a  
>>> revolutionary, historical or social palingenesis." - Luigi Nono
>>> */
>>>
>>>
>>> _______________________________________________
>>> sc-dev mailing list
>>>
>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/ 
>>> sc_mailing_lists.shtml
>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/ 
>> sc_mailing_lists.shtml
>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>
> ******************************************
> /* Joshua D. Parmenter
> http://www.realizedsound.net/josh/
>
> “Every composer – at all times and in all cases – gives his own  
> interpretation of how modern society is structured: whether  
> actively or passively, consciously or unconsciously, he makes  
> choices in this regard. He may be conservative or he may subject  
> himself to continual renewal; or he may strive for a revolutionary,  
> historical or social palingenesis." - Luigi Nono
> */
>
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/ 
> sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
< Prev | 1 - 2 - 3 | Next >