James Harkins | 1 Jun 2009 05:01
Picon

incomplete replacement by asOSCArgArray in Node.sc

One good thing about the 3.3.1 delay is it gave me time to find some  
pretty serious badness in Node.sc -- we are not currently using  
asOSCArgArray consistently for s_new messages (e.g., array arguments  
with Synth(...) is fine, but with x = Synth.basicNew(...); x.newMsg 
(args: ...), it's broken).

Attached diff... is this OK? Did I miss anything or change something  
I shouldn't have? (Not committed yet.)

hjh



: H. James Harkins
: jamshark70@...
: http://www.dewdrop-world.net
.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

Josh Parmenter | 1 Jun 2009 05:39

Re: Clip (and Wrap and Fold) UGens

Attached is a diff for Clip. A couple things that need to be decided  
though. The big thing is whether or not to check if low is indeed  
lower then high (the old version did this). I can't think of an  
efficient way to do this at different rates, so it can either do what  
the attached does (funky things - basically it outputs high), output  
0, or do the same check the old one did ( if low > high, low = high  
and high = low).

Any comments are welcome... I'm guessing we should do the check ...  
probably something like this in the loop would do it:

     for(int i = 0; i < inNumSamples; i++){
	if(hi > lo){
	    out[i] = sc_clip(in[i], lo, hi);
	} else {
	    out[i] = sc_clip(in[i], hi, lo);
	}
	
	lo += lo_slope;
	hi += hi_slope;
     };

and here is a simple test:

{ Clip.ar(SinOsc.ar(440, 0, 1), -0.07, MouseX.kr(-1, 1)) }.scope;

Best,

Josh

(Continue reading)

Julian Rohrhuber | 1 Jun 2009 19:31
Picon
Favicon

[commit?] envelope release bug fixed

Recently we noticed that the closing of a gate in EnvGen happens a 
control period late. This is problematic for crossfades. The problem 
seems to be an off by one in the envelope output when the gate is set 
to zero and releases the envelope.

I've attached a diff that solves the issue by handling the release 
mode differently than the rest in the next_k method.

Any objections to committing this?
--

-- 

.
Attachment (envGate.diff): application/octet-stream, 541 bytes
Batuhan Bozkurt | 1 Jun 2009 23:10

allowReselection for cocoa PopUpMenu?

Hi all,

I've noticed that the swing gui has an option for allowing reselection  
(running the action even if the readily selected item is reselected  
again) from a popup menu. Before I start investigating on a way for  
adding an option for it, I'd like to know if there are any obvious  
technical barriers behind the unavailability of this on cocoa.

Thanks,
Batuhan

_______________________________________________
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/

jamshark70 | 2 Jun 2009 14:18
Picon

SF.net SVN: supercollider:[9194] trunk/build/SCClassLibrary/Common/Control/ Node.sc

Revision: 9194
          http://supercollider.svn.sourceforge.net/supercollider/?rev=9194&view=rev
Author:   jamshark70
Date:     2009-06-02 12:18:20 +0000 (Tue, 02 Jun 2009)

Log Message:
-----------
Fix several occurrences of asControlInput that should have been asOSCArgArray

Modified Paths:
--------------
    trunk/build/SCClassLibrary/Common/Control/Node.sc

Modified: trunk/build/SCClassLibrary/Common/Control/Node.sc
===================================================================
--- trunk/build/SCClassLibrary/Common/Control/Node.sc	2009-05-31 15:30:41 UTC (rev 9193)
+++ trunk/build/SCClassLibrary/Common/Control/Node.sc	2009-06-02 12:18:20 UTC (rev 9194)
 <at>  <at>  -418,7 +418,7  <at>  <at> 
 		synth = this.basicNew(defName, server);
 		if((addNum < 2), { synth.group = inTarget; }, { synth.group = inTarget.group; });
 		server.sendBundle(nil, [9, defName, synth.nodeID, addNum, inTarget.nodeID] ++ 
-			args.asControlInput, [12, synth.nodeID, 0]); // "s_new" + "/n_run"
+			args.asOSCArgArray, [12, synth.nodeID, 0]); // "s_new" + "/n_run"
 		^synth
 	}
 		/** does not send	(used for bundling) **/
 <at>  <at>  -432,7 +432,7  <at>  <at> 
 		// if target is nil set to default group of server specified when basicNew was called
 		inTarget = (target ? server.defaultGroup).asTarget;
 		(addNum < 2).if({ group = inTarget; }, { group = inTarget.group; });
(Continue reading)

jrhb | 2 Jun 2009 15:43
Picon

SF.net SVN: supercollider:[9195] trunk/Source/plugins/LFUGens.cpp

Revision: 9195
          http://supercollider.svn.sourceforge.net/supercollider/?rev=9195&view=rev
Author:   jrhb
Date:     2009-06-02 13:43:03 +0000 (Tue, 02 Jun 2009)

Log Message:
-----------
EnvGen outputs level after first calculation in kr rate now. This fixes an off by one block latency in
envelope attacks and releases.

Modified Paths:
--------------
    trunk/Source/plugins/LFUGens.cpp

Modified: trunk/Source/plugins/LFUGens.cpp
===================================================================
--- trunk/Source/plugins/LFUGens.cpp	2009-06-02 12:18:20 UTC (rev 9194)
+++ trunk/Source/plugins/LFUGens.cpp	2009-06-02 13:43:03 UTC (rev 9195)
 <at>  <at>  -2262,7 +2262,7  <at>  <at> 
 		}
 	}

-	*out = level;
+	
 	switch (unit->m_shape) {
 		case shape_Step : {
 		} break;
 <at>  <at>  -2324,6 +2324,7  <at>  <at> 
 		case shape_Sustain : {
 		} break;
(Continue reading)

Julian Rohrhuber | 2 Jun 2009 15:49
Picon
Favicon

Re: [commit?] envelope release bug fixed

Actually  after thorough testing the problem was much simpler and 
more uniform  (tests attached).

I've committed the fix.

>Recently we noticed that the closing of a gate in EnvGen happens a 
>control period late. This is problematic for crossfades. The problem 
>seems to be an off by one in the envelope output when the gate is 
>set to zero and releases the envelope.
>
>
>I've attached a diff that solves the issue by handling the release 
>mode differently than the rest in the next_k method.
>
>Any objections to committing this?
>--
>
>
>
>
>
>.
>
>Attachment converted: data:envGate.diff (    /    ) (000C9C4F)

--

-- 

.
Attachment (envelope_gate_offset_problem.scd): application/octet-stream, 700 bytes
Dan Stowell | 2 Jun 2009 22:36
Picon

Re: [commit?] envelope release bug fixed

not been following this (no time atm, sorry) but remember changelog :)
strikes me as a change that someone might want to notice!

2009/6/2, Julian Rohrhuber <rohrhuber@...>:
> Actually  after thorough testing the problem was much simpler and more
> uniform  (tests attached).
>
>  I've committed the fix.
>
>
>
> > Recently we noticed that the closing of a gate in EnvGen happens a control
> period late. This is problematic for crossfades. The problem seems to be an
> off by one in the envelope output when the gate is set to zero and releases
> the envelope.
> >
> >
> > I've attached a diff that solves the issue by handling the release mode
> differently than the rest in the next_k method.
> >
> > Any objections to committing this?
> > --
> >
> >
> >
> >
> >
> > .
> >
> > Attachment converted: data:envGate.diff (    /    ) (000C9C4F)
(Continue reading)

James Harkins | 3 Jun 2009 05:16
Picon

Re: [sc-users] problems with ScrollView

On Jun 2, 2009, at 6:20 PM, Scott Wilson wrote:

The problem is that the whole relativeOrigin = true or false business is a boondoggle which serves no real purpose except to complicate code and bring out edge cases like this. All container views should behave as if relative = true. Then you wouldn't have to ask.

Put another way if(relativeOrigin, ...) is the wrong question, at least with a top view (which a scrollview is). In the short term isTopView would be a better question to ask first, but if we abolished relativeOrigin = false (which I think we should) you wouldn't need to ask a question at all, and we could greatly simplify a lot of code.

In principle I agree with this -- my concern is that we didn't do it for 3.3, and I'm not sure this is a good thing to do for a maintenance update. But it could be justified since 3.3.1 will (?) change the coordinates for user view mouse tracking, which is no less disruptive a change.

Whatever the solution is, it should minimize the amount that the user has to know about the GUI API. Forcing the user to be aware of the distinction between a composite and scrolling top view is splitting a hair that I suspect most users would find annoying rather than enlightening. From a usability perspective, I don't find isTopView convincing.

From that perspective as well, dumping absolute-bounded containers is certainly the cleanest.

If consensus of other developers is that it's too risky to break user code by dropping support for it without a deprecation period, then... we still have wrong behavior to fix. In that case, I think it would be beneficial to have some method whereby the user can determine whether a container view (defined as a parent view into which other views are placed, which would include composite view and scroll view both) measures coordinates from the top left of the window or not. If relativeOrigin is the wrong method name for that, I'm open to another name. But I confess, I don't see what is so objectionable about using the relativeOrigin getter.

There is no need to pass this as a property to the backend cocoa object for a scroll view. SCScrollView already has a dummy setter for relativeOrigin, which is right (or maybe it should throw a should not implement error). All I'm suggesting is to have a relativeOrigin getter in the class that returns true. This would not touch the backend objects in any way and not have any effect on drawing.

I do understand why this is a bit deceptive, but it's a useful deception. "Useful deception" is not a bad description of polymorphism in general, actually.

But again, if relativeOrigin is a bad name for it, I'm fine with calling it something else (or sidestepping the problem by getting rid of absolute bounds).

hjh


: H. James Harkins
.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

jamshark70 | 3 Jun 2009 14:02
Picon

SF.net SVN: supercollider:[9196] trunk/Source/app/SCTextView.M

Revision: 9196
          http://supercollider.svn.sourceforge.net/supercollider/?rev=9196&view=rev
Author:   jamshark70
Date:     2009-06-03 12:02:32 +0000 (Wed, 03 Jun 2009)

Log Message:
-----------
Add ctrl-return and shift-return as execute-code shortcuts in sc.app (committed now after repeated
discussions on list, after which I never got around to checking it in!)

Modified Paths:
--------------
    trunk/Source/app/SCTextView.M

Modified: trunk/Source/app/SCTextView.M
===================================================================
--- trunk/Source/app/SCTextView.M	2009-06-02 13:43:03 UTC (rev 9195)
+++ trunk/Source/app/SCTextView.M	2009-06-03 12:02:32 UTC (rev 9196)
 <at>  <at>  -186,7 +186,10  <at>  <at> 
 			pthread_mutex_unlock (&gLangMutex);
 		}
 	}
-    if ([characters isEqual:  <at> "\03"]) {
+		// shift- or control-return added by hjh
+    if ([characters isEqual:  <at> "\03"] ||
+			(([characters isEqual:  <at> "\n"] || [characters isEqual:  <at> "\r"])
+				&& ([event modifierFlags] & (NSControlKeyMask | NSShiftKeyMask)))) {
         [[self delegate] executeSelection: self];
     } else if (([characters isEqual:  <at> "\n"] || [characters isEqual:  <at> "\r"]) && !([event modifierFlags] &
NSAlternateKeyMask)) {
         [self autoIndent: event];

This was sent by the SourceForge.net collaborative development platform, the world's largest Open
Source development site.

_______________________________________________
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/


Gmane