[ANN] new development snapshot of muO available

hello list,

a new development snapshot of muO is available:
http://www.zogotounga.net/comp/squeak/sqgeo.htm

it can be installed in a 3.8 or 3.9 image (use fresh images for safety
and convenience)

muO is an experimental environment for musical composition


Stef

Stéphane Rollandin wrote:
> hello list,
>
> a new development snapshot of muO is available:
> http://www.zogotounga.net/comp/squeak/sqgeo.htm
>
> it can be installed in a 3.8 or 3.9 image (use fresh images for safety
> and convenience)
>
> muO is an experimental environment for musical composition

Great! I've been looking at it in 3.8 and I'm eager to move to 3.9.

BTW: is anyone working on completing the Linux MIDI plugin?

Ian: what do you think it would take to make the MIDI plugin talk to
ALSA MIDI? I have no experience with this, but since you did the ALSA
audio plugin, you might have come across ALSA's MIDI.


--
brad fuller
www.bradfuller.com

El 1/25/07 10:22 AM, "Stéphane Rollandin" <[hidden email]> escribió:
Dear Stéphane .
Your project is the most beautiful and amazing in the last times.
I load into the still unreleased 3.10alpha , just for as we intent major
changes, and your project is a challenge one for compatibility issues.

I must do some guess and assumptions, but have working.

In "MGraph registerExternalDropHandlers

(MGraphMusicFile newFromFile: dropStream fullName) openInHand]}. {'st'.
[:dropStream |

'.st' is used for code load , so you could consider a change ?

Could I put in the for external access 3.10 image ? Or you prefer do a later
time ?

Edgar

http://201.212.99.13:8088/
>From 09:00 to 20:00 GMT roughly



       

       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

Edgar J. De Cleene wrote:
> I load into the still unreleased 3.10alpha , just for as we intent major
> changes, and your project is a challenge one for compatibility issues.

indeed :)

> I must do some guess and assumptions, but have working.
>
> In "MGraph registerExternalDropHandlers
>
> (MGraphMusicFile newFromFile: dropStream fullName) openInHand]}. {'st'.
> [:dropStream |
>
> '.st' is used for code load , so you could consider a change ?

you are right, this will be changed in the next release.

see the attached file: I removed handling of .st, .cs, .sar, .morph and
projects since Squeak already takes care of this.

is it ok now ?


regards,

Stef

'From Squeak3.8 of ''5 May 2005'' [latest update: #6665] on 25 January 2007 at 10:28:15 pm'!

!MGraph class methodsFor: 'initialize' stamp: 'spfa 1/25/2007 22:28'!
registerExternalDropHandlers

        "MGraph registerExternalDropHandlers"

        "ExternalDropHandler initialize"

        {{'csd' . [:dropStream |
                                         (MGraphMusicFile newFromFile: dropStream fullName)
                                         openInHand]} .

         {'sco' . [:dropStream |
                                         (MGraphMusicFile newFromFile: dropStream fullName)
                                         openInHand]} .

         {'orc' . [:dropStream |
                                         (MGraphCsoundComposer newFromFile: dropStream fullName)
                                         openInHand]} .

         {'wav' . [:dropStream |
                                         (MGraphMusicFile newFromFile: dropStream fullName)
                                         openInHand]} .
         {'mid' . [:dropStream |
                                         (MGraphMusicFile newFromFile: dropStream fullName)
                                         openInHand]} .
         {'midi' . [:dropStream |
                                         (MGraphMusicFile newFromFile: dropStream fullName)
                                         openInHand]} .
  }
        do: [:ea |
                        ExternalDropHandler registerHandler:
                        (ExternalDropHandler type: nil
                                                                                extension: ea first
                                                                                action: ea second)].
! !

Hi Stef,

I've been listening to some of your compositions. They are beautiful.
muO is the coolest thing in music software in the last 3 or 4 years!

Thank you,
Juan Vuletich

Stéphane Rollandin escribió:

Stéphane Rollandin wrote: Hi Stef,

I've installed muO and started studying the documentation. It looks
really interesting.

I was working on a music project in squeak, too.

I wrote some morphs to represent notes and envelopes and wanted to send
events via OSC in realtime.

But I'm stuck since I haven't found how to keep precise timing (with a
decent resolution). My first prototypes used the Morph 'tick' method,
but this was unacceptable for obvious reasons. Lately I've been
experimenting with forking an osProcess, but I was wandering if there's
a cleaner/better method.

Can you provide me with some hints, or point me to the proper
documentation where I can found some explanation about how to achieve this?

Thanks in advance, and keep up with the good work.

c.

--
http://www.cesaremarilungo.com

Cesare,

> I wrote some morphs to represent notes and envelopes and wanted to send
> events via OSC in realtime.

Did you ever get Squeak to be able to send any OSC messages at all?
Are you using classes from Siren?  I'm very interested in this idea as
well.

Cheers,
Mike

The VM's attempt to provide 1 or 2 millisecond timing for servicing  
Delays.  I believe the windows VM offered 1 millisecond timing for  
awhile now.
The macintosh carbon and I guess the Unix Vm offer timing resolution  
historically in about a 2 or 3 ms window, but I see the code to do  
that has been
changed now to target a  1 ms window via the interpreter's setting of  
interruptChecksEveryNms, we did this 2004 I'd guess.

You could consider creating a set of Delays to fire in the future,  
have some task responsible for doing this based on the timing that  
you require, or you setup up
a delay to service the next task at the end of each task completion,  
and by tracking the latency (if any) you could ensure your code will  
run within a 1ms window.

Internally the VM attempts to check every millisecond for pending  
delays, or when not busy, sleeps until the next interrupt is required  
to be fired (or of course wakes up when an signal, or UI interrupt is  
needed to be serviced).

On Jan 28, 2007, at 11:13 AM, Cesare Marilungo wrote:

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

mike clemow wrote: No, I'm using Markus Gaelli package:

http://map.squeak.org/package/61f807be-83a3-4944-bfa1-686ddac7153c

Here's a snippet to send a pair of values:

(OSCMessage
        for: {'/pd/osc' . value1 . value2 })
        sendTo: (NetNameResolver localHostAddress)
        port: 9999.

- c.

--
http://www.cesaremarilungo.com

John M McIntosh wrote:
Thank you, John. I'll investigate this approach. I like the idea of
setting up a new Delay at every cycle.

Is it better than forking an osProcess?

Here is how I was doing this:

start
    running ifFalse: [ running _ true.].
    oldTime _ Time millisecondClockValue.
   
    [self doProcess] fork.



doProcess
       
        [running] whileTrue: [
        (Delay forMilliseconds: 1) wait.
        morphs do: [ :morph | morph advanceSecs:
            Time millisecondClockValue - oldTime.
            oldTime _ Time millisecondClockValue.]
        ].



--
http://www.cesaremarilungo.com

thanks !


Juan Vuletich wrote:
> Hi Stef,
>
> I've been listening to some of your compositions. They are beautiful.
> muO is the coolest thing in music software in the last 3 or 4 years!
>
> Thank you,
> Juan Vuletich

Cesare Marilungo wrote:
you can have a look at the code in MusicalPhrase>>outputToMidiPort:after:

that's what I came up with for tackling the same problem you're having.
I think it's very close to what John M McIntosh describes in its anwser.



Stef

Stéphane Rollandin wrote: Thank you. I'll study that part of your code, then.

c.

--
http://www.cesaremarilungo.com