Additional comments on Object>>is:

Hi -

Here are some additional comments on the issue of Object>>is: that I'd
like to bring forward:

1) I think about Object>>is: more as a generic membership test than a
protocol or inheritance test. This is why (for example) I would expect
to be able to do stuff like:

        Smalltalk is: #Squeak. "true on Squeak, false elsewhere"
        Smalltalk is: #Cuis.   "true on Cuis, false elsewhere"

There is no protocol called #Squeak; it's just a property that we
consider to be present on Smalltalk and able to test for. Consequently,
I'd expect objects by default to carry various tags, some static, some
dynamic.

2) I think people got way too side-tracked by my use of #isKindOf: which
was a simple implementation for something that should've read more like
this:

Object>>is: aSymbol
        ^self class isInstanceTag: aSymbol

and then:

Behavior>>isInstanceTag: aSymbol
        "Answer true if our instances should generically be considered to be
tagged by the given symbol. We consider instances tagged by the names of
their classes."

        "Here is a clever trick to avoid searching the entire class hierarchy
when the symbol doesn't identify a class name. Instead of traversing the
hierarchy, we look up the symbol from our environment and only if it's
present and a behavior we go on to see if we conform to the behavior.
That's the inverse process but much faster"
        self environment at: aSymbol ifPresent:[:aGlobal|
                aGlobal isBehavior ifTrue:[^self includesBehavior: aSymbol]
        ].

        ^false

I think this illustrates a little better what I was intending to
achieve. Juan - do you still feel that this is too "inheritance
oriented" or would you feel more comfortable with this version?

3) I think compatibility is important in this area. If we can't agree
that instances should be tagged by their corresponding classes (and
traits) then there is an alternative for my initial problem of
decoupling dependencies introduced via #isKindOf: by allowing #isKindOf:
to take a symbol as the argument. So instead of aMorph isKindOf:
SketchEditorMorph we'd use aMorph isKindOf: #SketchEditorMorph.

This certainly avoids the dependency and I'd be okay to use it. However,
actually taking the numbers in Cuis points out that 19 out of 21
implementors of #is: use their class name as the only tag (I haven't
looked at the 130 or so senders but I suspect a very similar ratio). In
other words, we have a > 90% correlation between the use of #is: and the
receiver's type. Given that high correlation I think it's worthwhile to
support it out of the box.

Cheers,
   - Andreas

Andreas Raab wrote:
Yes. The question is where to stop. #is: could be used to replace any
method that is a test for a boolean value. I guess going too far in this
direction could bring the issues raised by Stephane, like putting too
much meanings in a single method. For example, so far in Cuis I replaced
#isHandMorph with #is: HandMorph, but I did not replace #isWorldMorph,
because #isWorldMorph is dynamic. So far I only replaced methods that
just answer the true or false constant. I guess we'd need some
experience with actual use to know where to draw the limit of what's
good and what's bad to do in #is: .

This is better than the previous version. And it is quite reasonable if
you lean towards generic membership, including dynamic membership, and
not just protocols.

> 3) I think compatibility is important in this area. If we can't agree
> that instances should be tagged by their corresponding classes (and
> traits) then there is an alternative for my initial problem of
> decoupling dependencies introduced via #isKindOf: by allowing
> #isKindOf: to take a symbol as the argument. So instead of aMorph
> isKindOf: SketchEditorMorph we'd use aMorph isKindOf: #SketchEditorMorph.

Making #isKindOf: accept symbols is better than adding #isA:. Anyway, in
an ideal world, we'd never need to test for class membership, except,
perhaps, for a few low level operations that deal specially with special
kernel classes.

Right. So far I only used #is: to replace #isXXX methods, so it is
pretty much belonging to a class (actually to a hierarchy, as all
implementors of #is: do call super). However, being able to add
LightWidget and M3Morph on par with Morph, without having to add
knowledge about these new Morph-like classes, is what shows me that
thinking on protocol compliance is better than thinking on hierarchy. I
believe that in Cuis, when real redesign takes over simply replacing a
pattern with another, that 90% correlation could change. Only time will
tell.

Cheers,
Juan Vuletich

Andreas Raab wrote:
> This certainly avoids the dependency and I'd be okay to use it. However,
> actually taking the numbers in Cuis points out that 19 out of 21
> implementors of #is: use their class name as the only tag (I haven't
> looked at the 130 or so senders but I suspect a very similar ratio). In
> other words, we have a > 90% correlation between the use of #is: and the
> receiver's type. Given that high correlation I think it's worthwhile to
> support it out of the box.

The only concern I have with this is that it counts only positives, not
negatives, so to speak. It's making a protocol out of *every* class,
even those not currently used as protocols.

To look at it from a "negatives" point of view, there are 1262
subclasses of ProtoObject in Cuis 2.2, of which only 21 (1.7%) implement
#is:, so that's 1241 implicitly-defined protocols that there are no
users of.

This is why I think that being explicit about what an object #is: is
better than having it default to class names.

Regards,
  Tony

Hello all,

Wondering if there is something i have overlooked that would enable me to turn this sort of stuff:

#(#('c5' 0.1 300) #('c#5' 0.1 300) #('c5' 0.1 300) #('a5' 0.1 300) #('c5' 0.1 300) #('e5' 0.1 300) #('c5' 0.1 300) #('f5' 0.1 300) #('c5' 0.1 300) #('g#5' 0.1 300) #('g#5' 0.1 300) #('f5' 0.1 300) #('g#5' 0.1 300) #('e5' 0.1 300) #('g#5' 0.1 300) #('a5' 0.1 300) #('g#5' 0.1 300) #('c#5' 0.1 300) #('g#5' 0.1 300) #('c5' 0.1 300))

into a standard MIDI file...?

---

delightful workspace code:

s_PluckedSound new "FMSound clarinet2"  .
m_MixedSound new.    
       
notes_#(0 1 9 4 5 8)  .
pedal_#(1 2 1 3 1 4 1 5 1 6 6 5 6 4 6 3 6 2 6 1).

st_ReadStream  on:pedal.

oc_OrderedCollection new.

octave_'5'.
dur_0.1. "0625."
vol_300.

d_Dictionary new.
d at:0 put:'c';
at:1 put:'c#';
at:2 put:'d';
at:3 put:'d#';
at:4 put:'e';
at:5 put:'f';
at:6 put:'f#';
at:7 put:'g';
at:8 put:'g#';
at:9 put:'a';
at:10 put:'a#';
at:11 put:'b'.

[st atEnd]whileFalse:
[oc add:(Array with:((d at:((notes at:st next))),octave)with:dur with:vol)].
anArray_oc asArray.


m    add: (AbstractSound noteSequenceOn: s
        from: anArray ).
   
m play

---

i just want to turn THAT into a standard MIDI file... but if there were more "voices" added to the MixedSound, they should also work/show up :)

At this point, all i really care about is that the MIDI file produced would just convey the note, octave, duration, and volume information - nothing fancy (no extra/spiffy controllers)... i don't even care what "instrument" the midi file uses (except DRUMS) - as long as it just contains the correct note info :)

The goal? To see the notation in a program like Finale, MuseScore, or anything (that runs on Windows) that will show the notes as a music score.

I have looked into Siren and Musical Objects for Squeak, but did not find this feature - or at least no way for me to make sense of how to do it...  it probably is in there somewhere, but it seems that Siren at least has moved on to VW for the most part... also, MIDIFileReader is kinda the opposite of what i am looking for:

(MIDIFileReader(intent))reversed
does not work :)

i am kinda interested in seeing "standard" musical notation in Squeak, but that is entirely beyond my time and ability right now...

---

and finally: i am in the Seattle area and remembering the meetings i went to of:

http://www.halcyon.com/podenski/stug/
Puget Sound Smalltalk and Object-Oriented Database User Group

yeah, that looks grim :(

yet how great it was to discuss this squeak thing with brilliant folks in person...

---

thanks,

ken


     

Le 06/03/2010 10:47, Squeak List a écrit :
> Hello all,
>
> Wondering if there is something i have overlooked that would enable me to turn this sort of stuff:
>
> #(#('c5' 0.1 300) #('c#5' 0.1 300) #('c5' 0.1 300) #('a5' 0.1 300) #('c5' 0.1 300) #('e5' 0.1 300) #('c5' 0.1 300) #('f5' 0.1 300) #('c5' 0.1 300) #('g#5' 0.1 300) #('g#5' 0.1 300) #('f5' 0.1 300) #('g#5' 0.1 300) #('e5' 0.1 300) #('g#5' 0.1 300) #('a5' 0.1 300) #('g#5' 0.1 300) #('c#5' 0.1 300) #('g#5' 0.1 300) #('c5' 0.1 300))
>
> into a standard MIDI file...?

in muO (Musical Objects for Squeak)), there would be some (simple)
programming involved to convert your format for notes, but if you don't
mind using muO's own format the code would be:

'co5d19v120,c+,c,a,c,e,c,f,c,g+,g+,f,g+,e,g+,a,g+,c+,g+,c' kmusic
asMIDIFileNamed: 'mynotes.mid'

here d19 is the duration (0.1 second, but expressed in clicks with 96
clicks/seconds) and v120 is the midi volume.



Stef

> I have looked into Siren and Musical Objects for Squeak, but did not find this feature

I am very interested in improving muO documentation, so please report
your unsuccesses in finding features: they are good hints about what
needs to be done documentation-wise

cheers,

Stef

> here d19 is the duration (0.1 second, but expressed in clicks with 96
> clicks/seconds)

192 clicks/second, sorry

Stef,

thanks for your responses:)

hopefully we can iron out this particular issue via direct email and share with everyone :)

THANKS,

ken



----- Original Message ----
From: Stéphane Rollandin <[hidden email]>
To: The general-purpose Squeak developers list <[hidden email]>
Sent: Sat, March 6, 2010 2:24:22 AM
Subject: Re: [squeak-dev] AbstractSound 2 MIDI?

> I have looked into Siren and Musical Objects for Squeak, but did not find this feature

I am very interested in improving muO documentation, so please report your unsuccesses in finding features: they are good hints about what needs to be done documentation-wise

cheers,

Stef

Squeak List skrev 2010-03-06 10:47: This  ?:
http://guzdial.cc.gatech.edu/squeakers/MIDIFileWriter101.st

Karl

Karl,

Thanks for your reply.

not sure where the Knowledge Base went - or if this is accurate:

+++

MIDIFileWriter 1.01
converts a MIDIScore into a midifile...YAY!
To load in, modify, and save out a midi file, do this:

(scorePlayerMorph _ ScorePlayerMorph onMIDIFileNamed:'inputMidiFile.mid') openInWorld.
"play with the midi file...move notes around, etc."
"when done, do this:"
mfw _ MIDIFileWriter saveFileNamed: 'outputMidiFile.mid' fromScore: ((scorePlayerMorph scorePlayer) score).
mfw writeMidi.

+++

To simply test out how squeak converts your midifile, try this out:

midiScore _ MIDIFileReader scoreFromFileNamed: 'inputMidiFile.mid'
mfw _ MIDIFileWriter saveFileNamed: 'outputMidiFile.mid' fromScore: midiScore.
mfw writeMidi.

questions? comments? bugs? feature requests? code updates? check out the Knowledge Base
http://guzdial.cc.gatech.edu:8080/squeakers.179
[hidden email]

+++

http://guzdial.cc.gatech.edu:8080/squeakers.179

leads to the same dead end :(

this is a main point - at this point :)

btw, i have not tried sending any email to: [hidden email] - but from the mentioned dead end, i am not particularly motivated to try :(

what lead to that dead end is a further waste of time - it seems - THAT is why i inquire HERE.

+++


i have spent time with:

mfw _ MIDIFileWriter saveFileNamed: 'outputMidiFile.mid' fromScore: ((scorePlayerMorph scorePlayer) score).
mfw writeMidi. - part...)

possibly: some, most, or all of the ingredients are there, but not for the recipe i am seeking...

the recipe is kinda the opposite of what i want.

and even that it doesn't actually work as described - or at least as i would hope....

i can open and play a MIDI file in Squeak - no problem...

i can change the instruments in the Score (IN SQUEAK)

and
save the MIDI file...

and,

well,
the saved file plays back with the exact same instrument it was in the first place :(

the changes i made in Squeak do NOT make any difference in the saved MIDI file...meaning that NOTHING was changed in the MIDI file that Squeak produced - it sounds exactly the same....

and this is something i do not even particularly care about - as far as the "instrument" goes... but it does seem to be a possible "bug"... just try it: open a midi file - change the instrument(s) - save it VIA MIDIFileWriter - and see if it sounds different from the original....

Point is that everything i have found in the system (as far as what i would expect only from saving a MIDI file that was altered from within squeak merely changing the instrument) does not work...

BUT - as confusing as THAT is - IT is not what i want to do:

translate the fairly simple material from my original post to MIDI...

Thanks for your reply :)

ken









----- Original Message ----
From: Karl Ramberg <[hidden email]>
To: [hidden email]
Sent: Sat, March 6, 2010 4:14:02 AM
Subject: Re: [squeak-dev] AbstractSound 2 MIDI?

Squeak List skrev 2010-03-06 10:47: This  ?:
http://guzdial.cc.gatech.edu/squeakers/MIDIFileWriter101.st

Karl


     

hello all,
 
this has probably been asked endlessly, but here goes:
 
how can i "file out" all of the current changes i have made in Squeak?
 
situation: screen FULL of minimized workspaces that contain large amounts of working code which needs to find home(s) in the browser... best to print out the stuff and work it out on paper for the time being...
 
isn't there a simple way to file out all of the current workspace code? i can do it manually, but it would also be cool to not only file out workspace code, but also all of the changes i have made to base classes at the same time.
 
as far as changes to base classes: i don't need changes made 24 days ago that have been replaced/and re-changed - am not looking for a "history" of changes - just the current ones.
 
i would be happy with 1 text file that shows only all of the current changes i have made...
 
if this is built into Squeak, can someone PLEASE point it out?
 
or hint at, or spell out how to do it?
 
Thanks much,
 
ken