Timeline still buggy


    Jan 08 2007 | 2:41 pm
    I would really like to use timeline but in the past it was so buggy that I gave up. This morning I tried it again assuming that it had been fixed. The very first thing I tried caused max to crash.
    I opened the tutorial and dragged the envelope labeled "volume" a few ticks to the right. The crash has happen on each of the five times I retried it.
    I also tried pasting a new list into one of the message boxes at 8000. I reported this several years ago and it still doesn't work.
    Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson

    • Jan 08 2007 | 4:28 pm
      same with me: I tried edetonate some weeks ago and gave up because I could not navigate thru an imported MIDI file.
      falk
      Falk
      Am 08.01.2007 um 15:41 schrieb Gary Lee Nelson:
      > I would really like to use timeline but in the past it was so buggy > that I > gave up. This morning I tried it again assuming that it had been > fixed. > The very first thing I tried caused max to crash. > > I opened the tutorial and dragged the envelope labeled "volume" a > few ticks > to the right. The crash has happen on each of the five times I > retried it. > > I also tried pasting a new list into one of the message boxes at > 8000. I > reported this several years ago and it still doesn't work. > > Cheers > Gary Lee Nelson > Oberlin College > www.timara.oberlin.edu/GaryLeeNelson > >
    • Jan 08 2007 | 9:20 pm
      If you treat timeline like a handicapped friend (be glad about the things he CAN do), you'll get a lot out of it. You need to know its idiosyncrasies to make it work for you, though. I'm happy he's around.
      Speaking about idiosyncrasies, I can report that detonate still has its own too. Try to create entries for track 0 and track 33, for example; the limit should be 1 and 32.
      Georg
      On Jan 8, 2007, at 3:41 PM, Gary Lee Nelson wrote:
      > I would really like to use timeline but in the past it was so buggy > that I > gave up. This morning I tried it again assuming that it had been > fixed. > The very first thing I tried caused max to crash. > > I opened the tutorial and dragged the envelope labeled "volume" a > few ticks > to the right. The crash has happen on each of the five times I > retried it. > > I also tried pasting a new list into one of the message boxes at > 8000. I > reported this several years ago and it still doesn't work. > > Cheers > Gary Lee Nelson > Oberlin College > www.timara.oberlin.edu/GaryLeeNelson > >
    • Jan 08 2007 | 10:44 pm
      I've run into some of these weird problems with timeline too. Looks like a great idea but there's a lot of crashes so it's unnerving at best to use it...
      I'd love to see a version using jit.cellblock or even LCD that lets you indicate what's going on based upon graphical indicators. Maybe multiple "tracks", each with its own LCD, with a "scrub" bar that could be moved by hand or automatically (or mtr-recorded). It wouldn't have the same functionality as timeline, but I can imagine multiple colors meaning different messages or commands.
      Maybe jit.matrix (in an editable window) could also do this, or some kind of multislider configuration, or a bpfunction editor. Essentially, a collection of tracks of graphically-controlled messages that play / send messages to whatever you want. Could be neat.
      --CJ
    • Jan 08 2007 | 11:11 pm
      I suggest that if there's no viable solution in Max 5.0, those who are interested in a nice timeline object start collecting money Wikipedia style and contract a programming whiz to do the work. Lately, I had the pleasure working with Emmanuel Jourdan's js function object. Something similar could probably also be realized for timeline. If we all give $50, we might be able to raise a considerable amount.
      What does everybody think?
      Georg
      On Jan 8, 2007, at 11:44 PM, Seejay James wrote:
      > > I've run into some of these weird problems with timeline too. Looks > like a great idea but there's a lot of crashes so it's unnerving at > best to use it... > > I'd love to see a version using jit.cellblock or even LCD that lets > you indicate what's going on based upon graphical indicators. > Maybe multiple "tracks", each with its own LCD, with a "scrub" bar > that could be moved by hand or automatically (or mtr-recorded). It > wouldn't have the same functionality as timeline, but I can imagine > multiple colors meaning different messages or commands. > > Maybe jit.matrix (in an editable window) could also do this, or > some kind of multislider configuration, or a bpfunction editor. > Essentially, a collection of tracks of graphically-controlled > messages that play / send messages to whatever you want. Could be > neat. > > --CJ
    • Jan 08 2007 | 11:30 pm
      Im down for $50.. As long as it uses jitter @ attributes :)
      On Jan 8, 2007, at 6:11 PM, Georg Hajdu wrote:
      > I suggest that if there's no viable solution in Max 5.0, those who > are interested in a nice timeline object start collecting money > Wikipedia style and contract a programming whiz to do the work. > Lately, I had the pleasure working with Emmanuel Jourdan's js > function object. Something similar could probably also be realized > for timeline. If we all give $50, we might be able to raise a > considerable amount. > > What does everybody think? > > Georg > > On Jan 8, 2007, at 11:44 PM, Seejay James wrote:
      v a d e //
      www.vade.info abstrakt.vade.info
    • Jan 09 2007 | 12:10 am
    • Jan 09 2007 | 12:46 am
      I'm down as long as its an open system. the maxer needs to be able to add her own features like repeat, reverse, quantize,randomize etc... so I guess What I'm saying it can't just have a record and playback. its gotta integrate. (the difference between presets and pattr) a static one would be kind of useless.
      gotta run.
    • Jan 09 2007 | 8:59 am
    • Jan 09 2007 | 9:45 am
      The thought that MaxMSP 5.0 *won't* include a significant upgrade to the timeline object is too painful to consider. I would *love* an upgraded version, and I'm sure it's high on c74's "must have" list. I have a feeling that the deeeeep silence surrounding v5.0 is a good indication that they're really going above and beyond to make it something special. The whole graphical programming idea for music seems to really be taking hold (Reaktor, Audiomulch, Bidule, etc.), so I'm sure c74 wants to make their next major upgrade really shine, and to widen the gap between them and all these other apps -- I mean, I realize the gap is already pretty wide, since the integration of synthesis, processing, midi, and logic in MaxMSP is a far stretch beyond the competition, but still... (As an example of how far they *might* be going, some may recall the rumors of drool-worthy features like compositing in the main patcher window! "ooooh" --Merv Griffin-style. The more time I spend at the computer, the more I realize that interface design and user control are pretty lame in most commercial music software. And since Max is all about spurring the user's imagination, I'm sure c74 will give us lots to play with in order to help remedy the situation.)
      Anyway, I'd probably throw-down for a snazzy openGL timeline object. But I suspect c74 will provide one before we could actually get a 3rd-party one built. Personally, I think we should pool our money to pay the PWGL developers to incorporate OSC... then we'd have graphical options AND a super-hot score editor (which includes graphical notation as well, btw).
      J.
    • Jan 09 2007 | 10:03 am
      Seems I was wrong on this one.
      > solutions like Iannix
      Georg
    • Jan 09 2007 | 10:22 am
      hey! That looks promising... time to mess about!
      J.
    • Jan 09 2007 | 10:29 am
      Wow - maybe it's time to learn some of that OpenGL I've been hearing so much about :)
      Yeah I'd like to keep this thread alive too. I also had contemplated LCD, sounds like you guys got pretty far with it. It could still come in handy with some stuff I guess. Interested to see what you ended up with.
      Detonate could be nicely used as a timeline, especially if the notes were used as triggers, sending messages, storing numbers, etc. Maybe a track per pitch, with assignable behavior by velocity? Not to mention the other values.
      A concurrent, parallel Detonate (or multiple ones for that matter) could have the same notes / durations. Changing the velocity on these would control the level or type of effect in the main timeline sequence, depending on the value held by the "notes" in it---if the values are numbers it provides interpolation or scaling, if they are messages it changes the particular message sent (play sample2.aiff, play mtr / seq), or it turns on and off the “notes” (either the events happen or they don't). Lots of design possibilities and considerations there, with the advantage of the detonate UI and playback capabilities.
      For the messages that are in either of these examples: Common message “parts” could be stored in multiple drop-downs, so the user can build full messages piecemeal--take this action, on this name / symbol, at this level, etc. Combinations could then be stored too, in a coll and a drop-down.
      With a bit of mousestate and some transparent buttons you can make any object draggable (maybe hold down shift while in drag mode, or the reverse). Then you could do a fair bit with panels that “size themselves” automatically by setting the event’s duration / beat length. Choose common note lengths and drag them onto the tracks, with lots of preset patterns and filling functions, and a snap-to-grid function (use split object for the number of pixels around the nearest gridline, and an if-else to snap the panel and update the cursor? use modulus for the screen grid coordinates, based upon resolution and zoom level?).
      When you click a panel / event, you could edit the current number / list / message(s) it contains (a master editor panel at bottom switches to the current panel clicked). Also a master setter for the whole track, or whichever events are enabled to receive master track commands. The most recent screen coordinates of dragged or generated panels are stored for playback.
      Each track has independent playback rates; the note timings are determined using panel size and the screen pixel coordinates; there’s a slider above each track as an indicator and for scrubbing; there’s a range bar for looping; there’s a main level scaler for events that are numbers / lists; there’s maybe 6 levels of 2X zoom, out to about 4800 pixels horizontally; and there’s tons of presets / whatevers for all these… this sounds relatively doable, and would provide a lot of possibilities. Now let me just go and brew another pot…
      just thinkin’ out loud, so if you got this far, my appreciation
      C
    • Jan 09 2007 | 10:36 am
      I would like to chip in. I am desperate for a reliable "Timeline" environment. Let me know how to help (specifications etc),
      regards Pere Josep
      On 09/01/07, Georg Hajdu wrote: > > I suggest that if there's no viable solution in Max 5.0, those who > are interested in a nice timeline object start collecting money > Wikipedia style and contract a programming whiz to do the work. > Lately, I had the pleasure working with Emmanuel Jourdan's js > function object. Something similar could probably also be realized > for timeline. If we all give $50, we might be able to raise a > considerable amount. > > What does everybody think? > > Georg > > On Jan 8, 2007, at 11:44 PM, Seejay James wrote: > > > > > I've run into some of these weird problems with timeline too. Looks > > like a great idea but there's a lot of crashes so it's unnerving at > > best to use it... > > > > I'd love to see a version using jit.cellblock or even LCD that lets > > you indicate what's going on based upon graphical indicators. > > Maybe multiple "tracks", each with its own LCD, with a "scrub" bar > > that could be moved by hand or automatically (or mtr-recorded). It > > wouldn't have the same functionality as timeline, but I can imagine > > multiple colors meaning different messages or commands. > > > > Maybe jit.matrix (in an editable window) could also do this, or > > some kind of multislider configuration, or a bpfunction editor. > > Essentially, a collection of tracks of graphically-controlled > > messages that play / send messages to whatever you want. Could be > > neat. > > > > --CJ > >
      -- Course Leader Msc Creative and Computational Sound Creative Technologies Portsmouth University Eldon Building Winston Churchill Avenue Portsmouth PO1 2DJ 00 44 23 92 848484
      www.port.ac.uk/courses/coursetypes/postgraduate/MScCreativeAndComputationalSound/ www.perevillez.com www.centuryofnoise.com
    • Jan 09 2007 | 11:54 am
      Quote: pvillez@gmail.com wrote on Tue, 09 January 2007 11:36 ---------------------------------------------------- > I would like to chip in. I am desperate for a reliable "Timeline" > environment. Let me know how to help (specifications etc), > > regards Pere Josep
      I don't think max is ready to be used as a real sequencer and event editing solution. I started programming my own in Java a few months ago. It communicates with max via OSC, which works very nice.
      Mattijs
    • Jan 10 2007 | 2:33 am
      Gary (and others on Mac OS),
      You might want to look at iCE Tools as an alternative to timeline. It's a different paradigm, but ice.lattice is (a) simple, (b) reliable, and (c) stable.
      iCE Tools costs more than the $50 ante people have been positing in this thread, but its price is, frankly, more realistic given the work involved. As f.e has discovered, this sort of thing is not a trivial task. To give you an idea of just how much work was involved, note that ice.lattice needed almost 3 years development to market.
      I will respond to the question about availability for Windows in the thread in which the question was explicitly asked ("iCE sequencer opinions").
      Best, Peter
      On 8-Jan-2007, at 9:41, Gary Lee Nelson wrote: > I would really like to use timeline but in the past it was so buggy > that I > gave up. This morning I tried it again assuming that it had been > fixed. > The very first thing I tried caused max to crash.
      -------------- http://www.bek.no/~pcastine/Litter/ ------------- Peter Castine +--> Litter Power & Litter Bundle for Jitter Universal Binaries on the way iCE: Sequencing, Recording & Interface Building for |home | chez nous| Max/MSP Extremely cool |bei uns | i nostri| http://www.dspaudio.com/ http://www.castine.de
    • Jan 10 2007 | 3:39 am
      Peter, thanks for the information, I had considered ICE as it looks (on the surface) like the kind of thing I could use, but there is mention of standalone licensing restrictions on the website. What would these be?
      regards Pere
      On 10/01/07, Peter Castine wrote: > > Gary (and others on Mac OS), > > You might want to look at iCE Tools as an alternative to timeline. > It's a different paradigm, but ice.lattice is (a) simple, (b) > reliable, and (c) stable. > > iCE Tools costs more than the $50 ante people have been positing in > this thread, but its price is, frankly, more realistic given the work > involved. As f.e has discovered, this sort of thing is not a trivial > task. To give you an idea of just how much work was involved, note > that ice.lattice needed almost 3 years development to market. > > I will respond to the question about availability for Windows in the > thread in which the question was explicitly asked ("iCE sequencer > opinions"). > > Best, > Peter > > On 8-Jan-2007, at 9:41, Gary Lee Nelson wrote: > > I would really like to use timeline but in the past it was so buggy > > that I > > gave up. This morning I tried it again assuming that it had been > > fixed. > > The very first thing I tried caused max to crash. > > -------------- http://www.bek.no/~pcastine/Litter/ ------------- > Peter Castine +--> Litter Power & Litter Bundle for Jitter > Universal Binaries on the way > iCE: Sequencing, Recording & > Interface Building for |home | chez nous| > Max/MSP Extremely cool |bei uns | i nostri| > http://www.dspaudio.com/ http://www.castine.de > > >
    • Jan 10 2007 | 6:19 am
      Pattr sequencer!
      On Jan 9, 2007, at 9:33 PM, Peter Castine wrote:
      > Gary (and others on Mac OS), > > You might want to look at iCE Tools as an alternative to timeline. > It's a different paradigm, but ice.lattice is (a) simple, (b) > reliable, and (c) stable. > > iCE Tools costs more than the $50 ante people have been positing in > this thread, but its price is, frankly, more realistic given the > work involved. As f.e has discovered, this sort of thing is not a > trivial task. To give you an idea of just how much work was > involved, note that ice.lattice needed almost 3 years development > to market. > > I will respond to the question about availability for Windows in > the thread in which the question was explicitly asked ("iCE > sequencer opinions"). > > Best, > Peter > > On 8-Jan-2007, at 9:41, Gary Lee Nelson wrote: >> I would really like to use timeline but in the past it was so >> buggy that I >> gave up. This morning I tried it again assuming that it had been >> fixed. >> The very first thing I tried caused max to crash. > > -------------- http://www.bek.no/~pcastine/Litter/ ------------- > Peter Castine +--> Litter Power & Litter Bundle for Jitter > Universal Binaries on the way > iCE: Sequencing, Recording & > Interface Building for |home | chez nous| > Max/MSP Extremely cool |bei uns | i nostri| > http://www.dspaudio.com/ http://www.castine.de > >
      v a d e //
      www.vade.info abstrakt.vade.info
    • Jan 10 2007 | 10:19 am
    • Jan 10 2007 | 12:57 pm
      On Jan 10, 2007, at 1:19 AM, vade wrote: > Pattr sequencer!
      In a very simple way, you can already do this. Use an [mtr] object to record you preset changes for [pattrstorage]. Playback at will. I have done this to build layers for a recording of a composition. Worked like a charm.
      ------------------- Nathan Wolek, PhD --- nwolek@stetson.edu Assistant Professor of Music Technology Stetson University - DeLand, FL http://www.nathanwolek.com
    • Jan 10 2007 | 2:20 pm
      I considered mtr as an alternative to timeline but I cannot see how mtr can be made to participate in a pattr. Mtr is not an UI object. Do you have an example?
      BTW. I am having great success using textedit with pattr. With a small wrapper I have made a kind of qlist that is more easily edited and allows me to specify action times as well as delta times. As soon as I deliver my current piece I'll make up a small demo.
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson
      On 1/10/07 7:57 AM, "Nathan Wolek" wrote:
      > On Jan 10, 2007, at 1:19 AM, vade wrote: >> Pattr sequencer! > > In a very simple way, you can already do this. Use an [mtr] object > to record you preset changes for [pattrstorage]. Playback at will. > I have done this to build layers for a recording of a composition. > Worked like a charm. > > ------------------- > Nathan Wolek, PhD --- nwolek@stetson.edu > Assistant Professor of Music Technology > Stetson University - DeLand, FL > http://www.nathanwolek.com > >
    • Jan 10 2007 | 4:34 pm
      On 9-Jan-2007, at 22:39, Pere Josep Villez wrote: > Peter, thanks for the information, I had considered ICE as it looks > (on the surface) like the kind of thing I could use, but there is > mention of standalone licensing restrictions on the website. What > would these be?
      The page at the Kagi store has a Contact link specifically to answer this question. But since the question has been asked here, I'll answer it on list (not for the first time, probably not the last!-)
      It's basically a formality where you say to DSPA "I want to be able to build standalones with iCE Tools." That's all. DSPA requires an additional license, encompassing an assurance not to directly compete with DSPA's sequencer products. There are no additional license fees involved.
      Hope this helps, Peter
      -------------- http://www.bek.no/~pcastine/Litter/ ------------- Peter Castine +--> Litter Power & Litter Bundle for Jitter Universal Binaries on the way iCE: Sequencing, Recording & Interface Building for |home | chez nous| Max/MSP Extremely cool |bei uns | i nostri| http://www.dspaudio.com/ http://www.castine.de
    • Jan 10 2007 | 6:43 pm
      I've done the same things with the text object instead of mtr. But it doesn't seem like you can as easily scroll content in a textedit box, particularly when you deal with hundreds of lines.
      Georg
      On Jan 10, 2007, at 3:20 PM, Gary Lee Nelson wrote:
      > I considered mtr as an alternative to timeline but I cannot see how > mtr can > be made to participate in a pattr. Mtr is not an UI object. Do > you have an > example? > > BTW. I am having great success using textedit with pattr. With a > small > wrapper I have made a kind of qlist that is more easily edited and > allows me > to specify action times as well as delta times. As soon as I > deliver my > current piece I'll make up a small demo. > > Cheers > Gary Lee Nelson > Oberlin College > www.timara.oberlin.edu/GaryLeeNelson > > > On 1/10/07 7:57 AM, "Nathan Wolek" > wrote: > >> On Jan 10, 2007, at 1:19 AM, vade wrote: >>> Pattr sequencer! >> >> In a very simple way, you can already do this. Use an [mtr] object >> to record you preset changes for [pattrstorage]. Playback at will. >> I have done this to build layers for a recording of a composition. >> Worked like a charm. >> >> ------------------- >> Nathan Wolek, PhD --- nwolek@stetson.edu >> Assistant Professor of Music Technology >> Stetson University - DeLand, FL >> http://www.nathanwolek.com >> >> > > >
    • Jan 10 2007 | 6:57 pm
      Two questions prompted by this thread:
      1) how much functional example code is supplied alongside iCE Tools?
      2) what do we know about Max 5.0? Will we hear anything at NAMM or is it far too soon?
      -A
    • Jan 10 2007 | 7:16 pm
      Perhaps i should have said
      Pattr Timeline!
      There is a bit of a difference (perhaps in my head) between the two., being able to store not only your presets, but the time delta between them, etc. Yes, you could prob. finagle something, but there would be niceties of having something in the pattr family native.
      Anyway.
      On Jan 10, 2007, at 7:57 AM, Nathan Wolek wrote:
      > On Jan 10, 2007, at 1:19 AM, vade wrote: >> Pattr sequencer! > > In a very simple way, you can already do this. Use an [mtr] object > to record you preset changes for [pattrstorage]. Playback at > will. I have done this to build layers for a recording of a > composition. Worked like a charm. > > ------------------- > Nathan Wolek, PhD --- nwolek@stetson.edu > Assistant Professor of Music Technology > Stetson University - DeLand, FL > http://www.nathanwolek.com > >
      v a d e //
      www.vade.info abstrakt.vade.info
    • Jan 10 2007 | 7:32 pm
      Scrolling works by selecting text and dragging to the line you need. I am only dealing with 20-30 lines maximum. Saving segments in a pattrstorage.
      On 1/10/07 1:43 PM, "Georg Hajdu" wrote:
      > I've done the same things with the text object instead of mtr. But it > doesn't seem like you can as easily scroll content in a textedit box, > particularly when you deal with hundreds of lines. > > Georg
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson
    • Jan 10 2007 | 9:21 pm
      Nathan Wolek skrev: > On Jan 10, 2007, at 1:19 AM, vade wrote: >> Pattr sequencer! > > In a very simple way, you can already do this. Use an [mtr] object to > record you preset changes for [pattrstorage]. Playback at will. I > have done this to build layers for a recording of a composition. > Worked like a charm. That's what I do too. To me this is by far the most intuitive way of working with structures that change over time. Pattr friggin rules for this.
      Andreas.
    • Jan 10 2007 | 9:29 pm
      how about using jit.cellblock instead of textedit? each line would be a row in it, something like this:
      hth, nesa
    • Jan 10 2007 | 9:36 pm
      Yes, pattr seq timeline or something, but with layer flexibility. I like pattr a lot especially as I deal with a lot of transitional data over time. I agree keep it in this family of objects. Maybe easier said than done, but I can imagine an extension to the interpolation asoect of this class of objects.
      best Pere
      On 10/01/07, vade wrote: > > Perhaps i should have said > Pattr Timeline! > > There is a bit of a difference (perhaps in my head) between the two., > being able to store not only your presets, but the time delta between them, > etc. Yes, you could prob. finagle something, but there would be niceties of > having something in the pattr family native. > > Anyway. > > On Jan 10, 2007, at 7:57 AM, Nathan Wolek wrote: > > On Jan 10, 2007, at 1:19 AM, vade wrote: > > Pattr sequencer! > > > In a very simple way, you can already do this. Use an [mtr] object to > record you preset changes for [pattrstorage]. Playback at will. I have > done this to build layers for a recording of a composition. Worked like a > charm. > > ------------------- > Nathan Wolek, PhD --- nwolek@stetson.edu > Assistant Professor of Music Technology > Stetson University - DeLand, FL > http://www.nathanwolek.com > > > > > *v a d e //* > > *www.vade.info* > *abstrakt.vade.info* > > > > > > >
    • Jan 17 2007 | 3:15 am
      On Jan 10, 2007, at 9:20 AM, Gary Lee Nelson wrote: > Do you have an example?
      Sorry for the delay. As I said it is very simple. Store your presets then sequence them.
      ------ Nathan Wolek, PhD nathan@lowkeydigitalstudio.com http://www.lowkeydigitalstudio.com
    • Jan 17 2007 | 4:25 am
      Quote: vade wrote on Wed, 10 January 2007 11:16 ----------------------------------------------------
      > > Pattr Timeline! >
      agreed. something that stays in the [pattr] gang.
      Jeremy you might get the 50$ per timeline seeker ;)
      i would like to see a dynamic timeline where events writen in the past will have the possibility to influence what is to come in the future. which could make a "flexible" score which's content or stucture will always stay the same but vary according to any interactive means one can think about. this is a nice thread , i hope idea will keep flowing . best, ko
    • Jan 17 2007 | 6:35 am
      It would be nice to use a visual paradigm. For interactive work, it's always nicer to know what's inside that box. I appreciated Emmanuel's function editor with two synchronizable objects, one great for visual programming, the other optimized for efficiency.
      Georg
      On Jan 17, 2007, at 4:15 AM, Nathan Wolek wrote:
      > On Jan 10, 2007, at 9:20 AM, Gary Lee Nelson wrote: >> Do you have an example? > > Sorry for the delay. As I said it is very simple. Store your > presets then sequence them. > > ------ > Nathan Wolek, PhD > nathan@lowkeydigitalstudio.com > http://www.lowkeydigitalstudio.com > > > max v2; > #N vpatcher 10 59 464 312; > #P window setfont "Sans Serif" 9.; > #P window linecount 8; > #P comment 5 125 170 196617 RECORD 1) when mtr is set to record , > it will record changes in the selected preset 2) be sure to choose > stop when you are done 3) select play and your will have your > changes played back; > #P window linecount 3; > #P comment 5 81 169 196617 SELECT choose number from number box or > name from ubumenu; > #P window linecount 1; > #P hidden newex 504 99 48 196617 loadbang; > #P user umenu 295 138 61 196647 1 64 154 0; > #X add stop; > #X add record; > #X add play; > #X add mute; > #X add unmute; > #X add delay 0; > #X add first 0; > #X add read; > #X add write; > #X add clear; > #P newex 253 138 40 196617 mtr 2; > #N vpatcher 20 74 620 474; > #P window setfont "Sans Serif" 9.; > #P newex 201 51 56 196617 route text; > #P newex 50 51 40 196617 t b s b; > #P newex 90 51 109 196617 pack store 1 slotname; > #N vpatcher 10 59 230 306; > #P window setfont "Sans Serif" 9.; > #P newex 86 125 51 196617 zl ecils 1; > #P newex 108 164 62 196617 prepend set; > #P newex 86 102 67 196617 grab 1 to_ps; > #P message 86 84 79 196617 getslotname $1; > #N comlet (int) slotnum; > #P inlet 86 64 15 0; > #N comlet (msg) set textedit; > #P outlet 108 186 15 0; > #P connect 1 0 2 0; > #P connect 2 0 3 0; > #P connect 3 0 5 0; > #P connect 5 1 4 0; > #P connect 4 0 0 0; > #P pop; > #P newobj 259 50 96 196617 p retrieveslotname; > #P inlet 139 31 15 0; > #P inlet 259 30 15 0; > #P inlet 50 31 15 0; > #P inlet 201 31 15 0; > #P outlet 90 73 15 0; > #P outlet 80 73 15 0; > #P outlet 259 72 15 0; > #P outlet 50 73 15 0; > #P connect 5 0 10 0; > #P connect 10 0 0 0; > #P connect 10 2 2 0; > #P connect 10 1 9 0; > #P connect 9 0 3 0; > #P connect 7 0 9 1; > #P connect 11 0 9 2; > #P connect 4 0 11 0; > #P connect 6 0 8 0; > #P connect 8 0 1 0; > #P pop; > #P hidden newobj 415 64 85 196617 p presetmanager; > #P hidden button 487 100 15 0; > #P hidden toggle 394 237 15 0; > #P hidden message 408 237 78 196617 changemode $1; > #P hidden message 448 119 39 196617 set $1; > #P comment 254 87 97 196617 **select preset**; > #P window setfont "Sans Serif" 12.; > #P user ubumenu 302 100 112 196620 0 1 1 0; > #X add (undefined); > #X prefix_set 0 0 0; > #X pattrmode 1; > #P window setfont "Sans Serif" 9.; > #N vpatcher 10 59 267 338; > #P origin -448 -339; > #N comlet (bang) when done; > #P outlet 175 238 15 0; > #P button 175 216 15 0; > #P window setfont "Sans Serif" 9.; > #P window linecount 0; > #P newex 51 122 77 196617 route slotname; > #N comlet to ubumenu; > #P outlet 126 238 15 0; > #N comlet (bang) fill ubumenu; > #P inlet 51 31 15 0; > #P newex 51 55 22 196617 b 1; > #P newex 51 102 67 196617 grab 1 to_ps; > #P window linecount 1; > #P newex 51 167 31 196617 t 0 b; > #P newex 98 167 55 196617 unpack 0 s; > #P newex 143 188 75 196617 prepend append; > #P newex 51 75 121 196617 t getslotnamelist 1 clear; > #P newex 51 142 57 196617 route done; > #P newex 126 209 27 196617 gate; > #P connect 8 0 7 0; > #P connect 7 0 2 0; > #P connect 2 0 6 0; > #P connect 6 0 10 0; > #P connect 10 0 1 0; > #P connect 1 0 5 0; > #P connect 1 1 4 0; > #P connect 2 1 0 0; > #P fasten 5 0 0 0 56 203 131 203; > #P connect 2 2 9 0; > #P connect 0 0 9 0; > #P connect 4 1 3 0; > #P connect 3 0 0 1; > #P connect 5 1 11 0; > #P connect 11 0 12 0; > #P pop; > #P hidden newobj 413 100 74 196617 p slot_manage; > #P window setfont "Sans Serif" 12.; > #P user ubumenu 192 63 75 196620 0 1 1 0; > #X add store; > #X add insert; > #X prefix_set 0 0 0; > #X pattrmode 1; > #P window setfont "Sans Serif" 10.; > #P user textedit 302 63 414 83 32896 3 10 (undefined); > #P window setfont "Sans Serif" 12.; > #P user ubumenu 191 100 76 196620 0 1 1 0; > #X add read; > #X add write; > #X add writeagain; > #X add getclientlist; > #X prefix_set 0 0 0; > #X pattrmode 1; > #P window setfont "Sans Serif" 9.; > #P hidden newex 193 253 42 196617 r to_ps; > #P window setfont "Sans Serif" 12.; > #P number 267 100 35 12 0 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0; > #P number 267 63 35 12 0 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0; > #P window setfont "Sans Serif" 9.; > #P hidden newex 236 253 248 196617 pattrstorage my_presets > @changemode 1 @greedy 1; > #X client_rect 0 0 640 240; > #X storage_rect 0 0 640 240; > #P objectname my_presets; > #P comment 254 50 91 196617 **store preset**; > #P window linecount 4; > #P comment 4 27 170 196617 STORE 1) select number using number box > 2) enter name in textbox 3) click store from ubumenu; > #P hidden connect 4 0 2 0; > #P hidden connect 13 0 2 0; > #P hidden connect 6 1 2 0; > #P hidden connect 5 0 2 0; > #P hidden connect 16 2 2 0; > #P hidden connect 18 1 17 0; > #P hidden connect 17 1 4 0; > #P hidden connect 10 0 4 0; > #P hidden connect 4 0 17 1; > #P hidden connect 16 1 7 0; > #P hidden connect 16 3 7 0; > #P hidden connect 9 0 10 0; > #P hidden connect 12 0 10 0; > #P hidden connect 14 0 13 0; > #P hidden connect 16 0 9 0; > #P hidden connect 15 0 9 0; > #P hidden connect 8 1 16 0; > #P hidden connect 3 0 16 1; > #P hidden connect 4 0 12 0; > #P hidden connect 9 1 12 0; > #P hidden connect 7 0 16 2; > #P hidden connect 19 0 15 0; > #P hidden connect 3 0 16 3; > #P pop; > > >
    • Jan 17 2007 | 1:08 pm
      On Jan 17, 2007, at 1:35 AM, Georg Hajdu wrote: > It would be nice to use a visual paradigm. For interactive work, > it's always nicer to know what's inside that box.
      I agree! but I was just showing how one can currently deploy the a limited method of automatic preset changes for [pattrstorage].
      I hope my use of "simple" was not misinterpreted to mean that this is "easy to do already". It was a comment on the level of functionality. "simple" = limited, basic, etc.
      --Nathan
    • Jan 17 2007 | 1:37 pm
      Am I missing something. timeline and detonate come with Max/MSP. Shouldn't they work already?
      On 1/16/07 11:25 PM, "karl-otto von oertzen" wrote:
      > > Quote: vade wrote on Wed, 10 January 2007 11:16 > ---------------------------------------------------- > >> >> Pattr Timeline! >> > > agreed. something that stays in the [pattr] gang. > > Jeremy you might get the 50$ per timeline seeker ;) > > i would like to see a dynamic timeline where events writen in the past will > have the possibility to influence what is to come in the future. which could > make a "flexible" score which's content or stucture will always stay the same > but vary according to any interactive means one can think about. > this is a nice thread , i hope idea will keep flowing . > best, > ko > > > -- > karrrlo > www.marswalkers.org > www.fleeingbirds.org
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson
    • Jan 17 2007 | 5:27 pm
      Hi Nathan,
      I appreciated your example. My comments were less directed at you as they were at Cycling '74; once again stressing the need of a visual sequencing solution. I hope you didn't misunderstand my intentions.
      Georg
      On Jan 17, 2007, at 2:08 PM, Nathan Wolek wrote:
      > On Jan 17, 2007, at 1:35 AM, Georg Hajdu wrote: >> It would be nice to use a visual paradigm. For interactive work, >> it's always nicer to know what's inside that box. > > I agree! but I was just showing how one can currently deploy the a > limited method of automatic preset changes for [pattrstorage]. > > I hope my use of "simple" was not misinterpreted to mean that this > is "easy to do already". It was a comment on the level of > functionality. "simple" = limited, basic, etc. > > --Nathan >
    • Jan 17 2007 | 6:18 pm
      Quote: Georg Hajdu wrote on Wed, 17 January 2007 18:27 ---------------------------------------------------- > Hi Nathan, > > I appreciated your example. My comments were less directed at you as > they were at Cycling '74; once again stressing the need of a visual > sequencing solution. I hope you didn't misunderstand my intentions.
      Hi Georg,
      I don't agree with you on this. A complete visual sequencing solution is in fact a sequencer. Anything short of that would not be usable in a sensible way, so isn't worth making.
      To make a real sequencer takes enough time and effort to call it a separate product (such as Logic, Cubase, Live, etc). If Cycling '74 came to release a separate sequencer, I would probably be the first one to buy it and pay an amount of money separate from the 850,- that I paid for Max.
      In short, if you need to sequence events in Max, use an existing sequencer tool. Looking at the various options available to link max to other software, I'd say that is a very real option.
      Cheers, Mattijs
      > Georg > > On Jan 17, 2007, at 2:08 PM, Nathan Wolek wrote: > > > On Jan 17, 2007, at 1:35 AM, Georg Hajdu wrote: > >> It would be nice to use a visual paradigm. For interactive work, > >> it's always nicer to know what's inside that box. > > > > I agree! but I was just showing how one can currently deploy the a > > limited method of automatic preset changes for [pattrstorage]. > > > > I hope my use of "simple" was not misinterpreted to mean that this > > is "easy to do already". It was a comment on the level of > > functionality. "simple" = limited, basic, etc. > > > > --Nathan > > > > ----------------------------------------------------
    • Jan 17 2007 | 6:28 pm
      On Jan 17, 2007, at 12:27 PM, Georg Hajdu wrote: > I hope you didn't misunderstand my intentions.
      Noted. Thanks.
      ------------------- Nathan Wolek, PhD --- nwolek@stetson.edu Assistant Professor of Music Technology Stetson University - DeLand, FL http://www.nathanwolek.com
    • Jan 17 2007 | 6:35 pm
      "In short, if you need to sequence events in Max, use an existing sequencer tool."
      hmmm... except that a Max sequencing object would easily deal with the sequencing of arbitrary data -- messages, ints (> 127), floats, lists, and so on. That's not at all straightforward to do in a standard sequencer. Timeline was intended for this job, but it definitely needs an overhaul.
      J.
    • Jan 17 2007 | 7:17 pm
      On 17-Jan-2007, at 18:35, jbmaxwell wrote:
      > except that a Max sequencing object would easily deal with the > sequencing of arbitrary data -- messages, ints (> 127), floats, > lists, and so on.
      Dare I say it?
      If you want a sequencer that deals with arbitrary Max messages--and yes, I mean *anything*and*all*of*the*above*--then you should look at iCE Tools' lattice object.
      Best, Peter
      -------------- http://www.bek.no/~pcastine/Litter/ ------------- Peter Castine +--> Litter Power & Litter Bundle for Jitter Universal Binaries on the way iCE: Sequencing, Recording & Interface Building for |home | chez nous| Max/MSP Extremely cool |bei uns | i nostri| http://www.dspaudio.com/ http://www.castine.de
    • Jan 17 2007 | 7:25 pm
      Easier said than done, unless you've released a demo version in the meantime.
      jb
      Am 17.01.2007 um 20:17 schrieb Peter Castine:
      > you should look at iCE Tools' lattice object
    • Jan 17 2007 | 8:12 pm
      On 17-Jan-2007, at 20:25, Jeremy Bernstein wrote:
      > Easier said than done, unless you've released a demo version in the > meantime.
      We have vastly expanded information on the web site, both in English and Japanese. And we are very close to a distributable demo of Nortron, which demos the power of iCE Tools nicely (although it only shows a subset of what iCE can do).
      Your point is well taken, and DSPAudio is moving forward on the iCE Demo front. But *that* is also easier said than done.
      Best -- Peter
      PS: I think our Japanese information is even more extensive than the English version, but it's hard for me to tell. Japanese is not one of my languages.
      -------------- http://www.bek.no/~pcastine/Litter/ ------------- Peter Castine +--> Litter Power & Litter Bundle for Jitter Universal Binaries on the way iCE: Sequencing, Recording & Interface Building for |home | chez nous| Max/MSP Extremely cool |bei uns | i nostri| http://www.dspaudio.com/ http://www.castine.de
    • Jan 17 2007 | 8:12 pm
      This is exactly what I am trying to do. I want to send a message at a specified time and I want to be able to adjust the action time visually by dragging the message box around. Except for random crashes and the inability to paste text into the messages, timeline is perfect.
      On 1/17/07 1:35 PM, "jbmaxwell" wrote:
      > > "In short, if you need to sequence events in Max, use an existing sequencer > tool." > > hmmm... except that a Max sequencing object would easily deal with the > sequencing of arbitrary data -- messages, ints (> 127), floats, lists, and so > on. That's not at all straightforward to do in a standard sequencer. Timeline > was intended for this job, but it definitely needs an overhaul. > > J.
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson
    • Jan 17 2007 | 8:42 pm
      my example was indeed not so different then what [detonate] and [timeline] can do. my idea , and i should have been more precise, was in reference to the [pattr] world. i was thinking about a [pattr timeline] which would have its own window like the [pattrstorage]'s storage&client windows. maybe it should be just an extra feature for [pattrstorage]. i think the [pattr] realm allows much more flexibility than the [tiCmd] or using "action patches" in [timeline]. since we can already memorize any state of any GUI,interpolate between states it could be easy to sequence, order, permutate states at will. plus you could maybe write an XML sheet of your [pattrTimeline]. in that way we would have an universal system in storing, recalling, manipulating, interpolating, sequencing data in Max and we would not be limited by midi ranges anymore.
      my understanding of [detonate] is that you are limited to midi values, being in 0. to 1. range would be more advantageous in my opinion.
      Quote: Gary Lee Nelson wrote on Wed, 17 January 2007 05:37 ---------------------------------------------------- > Am I missing something. timeline and detonate come with Max/MSP. Shouldn't > they work already? > > > On 1/16/07 11:25 PM, "karl-otto von oertzen" wrote: > > > > > Quote: vade wrote on Wed, 10 January 2007 11:16 > > ---------------------------------------------------- > > > >> > >> Pattr Timeline! > >> > > > > agreed. something that stays in the [pattr] gang. > > > > Jeremy you might get the 50$ per timeline seeker ;) > > > > i would like to see a dynamic timeline where events writen in the past will > > have the possibility to influence what is to come in the future. which could > > make a "flexible" score which's content or stucture will always stay the same > > but vary according to any interactive means one can think about. > > this is a nice thread , i hope idea will keep flowing . > > best, > > ko > > > > > > -- > > karrrlo > > www.marswalkers.org > > www.fleeingbirds.org > > > Cheers > Gary Lee Nelson > Oberlin College > www.timara.oberlin.edu/GaryLeeNelson > > > ----------------------------------------------------
    • Jan 17 2007 | 9:20 pm
      I also think what is interesting is the abiity of some software to buffer the state of the system up to 'n' seconds ago, and being able to scratch/manipulate and shuttle through the 'past', release the playhead of the timeline and interpolate to the 'present'. This is particularly interesting in video when you have multiple layers, 3D, etc (well, in my opinion). Ive done some things close to this in Max, outside of pattr, but its rather intensive and not very elegant.
      Anyway.... just throwing it out there.
      I am currently struggling with some seemingly simple scheduling/ timeline style problems, and am having a hell of a time. *sigh*
      On Jan 17, 2007, at 3:42 PM, karl-otto von oertzen wrote:
      > > my example was indeed not so different then what [detonate] and > [timeline] can do. > my idea , and i should have been more precise, was in reference to > the [pattr] world. i was thinking about a [pattr timeline] which > would have its own window like the [pattrstorage]'s storage&client > windows. maybe it should be just an extra feature for > [pattrstorage]. i think the [pattr] realm allows much more > flexibility than the [tiCmd] or using "action patches" in [timeline]. > since we can already memorize any state of any GUI,interpolate > between states it could be easy to sequence, order, permutate > states at will. > plus you could maybe write an XML sheet of your [pattrTimeline]. > in that way we would have an universal system in storing, > recalling, manipulating, interpolating, sequencing data in Max and > we would not be limited by midi ranges anymore. > > my understanding of [detonate] is that you are limited to midi > values, being in 0. to 1. range would be more advantageous in my > opinion. > > > > Quote: Gary Lee Nelson wrote on Wed, 17 January 2007 05:37 > ---------------------------------------------------- >> Am I missing something. timeline and detonate come with Max/MSP. >> Shouldn't >> they work already? >> >> >> On 1/16/07 11:25 PM, "karl-otto von oertzen" >> wrote: >> >>> >>> Quote: vade wrote on Wed, 10 January 2007 11:16 >>> ---------------------------------------------------- >>> >>>> >>>> Pattr Timeline! >>>> >>> >>> agreed. something that stays in the [pattr] gang. >>> >>> Jeremy you might get the 50$ per timeline seeker ;) >>> >>> i would like to see a dynamic timeline where events writen in the >>> past will >>> have the possibility to influence what is to come in the future. >>> which could >>> make a "flexible" score which's content or stucture will always >>> stay the same >>> but vary according to any interactive means one can think about. >>> this is a nice thread , i hope idea will keep flowing . >>> best, >>> ko >>> >>> >>> -- >>> karrrlo >>> www.marswalkers.org >>> www.fleeingbirds.org >> >> >> Cheers >> Gary Lee Nelson >> Oberlin College >> www.timara.oberlin.edu/GaryLeeNelson >> >> >> > ---------------------------------------------------- > > > -- > karrrlo > www.marswalkers.org > www.fleeingbirds.org
      v a d e //
      www.vade.info abstrakt.vade.info
    • Jan 17 2007 | 10:45 pm
      Gary Lee Nelson wrote: > Am I missing something. timeline and detonate come with Max/MSP. Shouldn't > they work already?
      The thread subject is still valid...
      But to dream on: I'd like to go beyond classic sequencers. As a sequencer is defined as a sequence of events. But in favor of the way of thinking of Xenakis, there is a demand for the continuum. (The word timeline would still fit, a sequencer would be a step back...
      I guess I have to do it, the ultimate successor of the UPIC as Maxpatch... Any Bounties for that??? ;-)
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Jan 18 2007 | 12:07 am
      Sorry if I confused things. I only mentioned detonate because, like timeline, it does work as described. Gave up on in almost a year ago.
      On 1/17/07 3:42 PM, "karl-otto von oertzen" wrote:
      > > my example was indeed not so different then what [detonate] and [timeline] can > do. > my idea , and i should have been more precise, was in reference to the [pattr] > world. i was thinking about a [pattr timeline] which would have its own window > like the [pattrstorage]'s storage&client windows. maybe it should be just an > extra feature for [pattrstorage]. i think the [pattr] realm allows much more > flexibility than the [tiCmd] or using "action patches" in [timeline]. > since we can already memorize any state of any GUI,interpolate between states > it could be easy to sequence, order, permutate states at will. > plus you could maybe write an XML sheet of your [pattrTimeline]. > in that way we would have an universal system in storing, recalling, > manipulating, interpolating, sequencing data in Max and we would not be > limited by midi ranges anymore. > > my understanding of [detonate] is that you are limited to midi values, being > in 0. to 1. range would be more advantageous in my opinion. > > > > Quote: Gary Lee Nelson wrote on Wed, 17 January 2007 05:37 > ---------------------------------------------------- >> Am I missing something. timeline and detonate come with Max/MSP. Shouldn't >> they work already? >> >> >> On 1/16/07 11:25 PM, "karl-otto von oertzen" wrote: >> >>> >>> Quote: vade wrote on Wed, 10 January 2007 11:16 >>> ---------------------------------------------------- >>> >>>> >>>> Pattr Timeline! >>>> >>> >>> agreed. something that stays in the [pattr] gang. >>> >>> Jeremy you might get the 50$ per timeline seeker ;) >>> >>> i would like to see a dynamic timeline where events writen in the past will >>> have the possibility to influence what is to come in the future. which could >>> make a "flexible" score which's content or stucture will always stay the >>> same >>> but vary according to any interactive means one can think about. >>> this is a nice thread , i hope idea will keep flowing . >>> best, >>> ko >>> >>> >>> -- >>> karrrlo >>> www.marswalkers.org >>> www.fleeingbirds.org >> >> >> Cheers >> Gary Lee Nelson >> Oberlin College >> www.timara.oberlin.edu/GaryLeeNelson >> >> >> > ---------------------------------------------------- > > > -- > karrrlo > www.marswalkers.org > www.fleeingbirds.org
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson
    • Jan 18 2007 | 3:01 am
      Why not use detonate or a multislider with a limited range of values, then route the outcoming values to send settable messages? That could give a lot of flexibility.
      Another option is to actually have draggable message boxes whose text is settable (maybe with drop-downs that can also be loaded via a textedit or dialog, for commonly-used messages). The problem then becomes the length of the actual message and the size they become pixel-wise. And, would a message get sent once, or continue to be sent during its pixel "duration"? What about overlapping messages? Technically it's not a huge deal, but usability might be a problem.
      For draggable objects I'd choose panels instead (also color-coordinate-able) that would be sizeable based upon a subdivision of the overall timeline (or a measure therein). That way the message length doesn't affect the screen size. Shift-clicking could open up the message / value for setting, click to drag, maybe hold down "s" for a snap-to feature. Of course you'd have to keep a coll of screen coordinates for each panel / beat, to be read upon playback.
      I developed a prototype and it certainly took considerable doing but is totally possible, though of course as with all things in Max, complexities always creep in as you decide you've just GOT to have more functionality...... so it's still very much in-progress. The "draggable" sub-patch is itself considerably more complex than I wanted, but it deals with the modifier keys and the snap-to-grid feature, so there's a lot going on. With a lot of draggable objects, this would be a very unwieldy patch, so I plan to re-think it considerably (probably use an actual object rather than a subpatch, which--I believe--is more optimized? does anyone know?)
      -C
    • Jan 18 2007 | 7:34 am
      ..what's the problem with a simple sequencer object like a stipped down piano-roll/timeline similar to the editor window in "M"..would it be so difficult to program an objetct like this (simple functions like cut/paste, midi-in, quantize..)?..i know out there there are tons of commercial ones.Detonate/timeline could do something like this but i my opinion (and as this nice thread is showing..)they lack ease of use.. best mic
    • Jan 18 2007 | 9:25 am
    • Jan 18 2007 | 9:58 am
      Quote: Mattijs wrote on Thu, 18 January 2007 10:25 ---------------------------------------------------- > A simple sequencer object will lack ease of use too. I can promise you that you're not going to write a song in 'a simple sequencer object', neither in detonate, timeline, or seq. > > Mattijs
      !!..well ok..your right, one could even not be able to write a song with a full fledged sequencer..i mean, i'd like to have an easy timeline/sequencer in max to put in my patches when i need it mic
    • Jan 18 2007 | 10:01 am
      reaktor, bidule have this..it'just a wish, i can live without it :-)
    • Jan 18 2007 | 10:57 am
      Lately, I've been kind of obsessed with the idea of new sequencing paradigms. Sequencing GUIs are just so boring to me, these days; so flat, so musically vague. Ableton Live is kind of interesting, but somewhat limited in use, as is something like Sonasphere. What I'd be curious to see is a real 3D "world" type of paradigm. A space in which events are objects with form, colour, texture, and substance, and in which events visually show their relationships. Maybe offering various "views" on the sequence, prioritizing different notions of organization and relationship. I mean, in a program like Logic we've got a standard timeline, (crappy) score, piano scroll, and text-based event lists, but all of these paradigms are essentially unrelated to one another, visually speaking. The interface actually communicates very little about the relationships between events. (Okay, the piano scroll has a general metaphor of up/down for pitch and left/right/length for time/duration, but these are quite limited ways of visualizing music).
      There are visual metaphors that could actually communicate something about auditory relationships -- like transparency or size mapping to amplitude, in which case one could actually *see* the notion of masking. Or using fog for audio event boundaries, thus communicating the notion of sound dissipation or the effects of proximity on amplitude (also, crossfades and mixing). Or, conversely, using planes or "walls" to specify abrupt boundaries for audio events. Or texture for... well... texture. You get the idea. Of course, there are a vast number of possibilites, and problems with every one, I'm sure. But it often seems to me that all imagination around the visual representation of musical concepts in software dried up sometime in the '90s. Am I wrong?
      Of course, I'm not taking anything away from the ice tools. Not to mention the fact that all this visual stuff would eat CPU cycles for breakfast (though I guess a lot of it could be done on the graphics card). Mostly I'm just blabbing. I'm actually very curious about the ice tools, and will certainly keep my ear to the ground for more information, user experiences, and so on.
      J.
    • Jan 18 2007 | 11:31 am
      I share your obsession. In fact I am currently programming a visual sequencer interface for myself -and- turning logic inside out to link it to max, which is why I spend a lot of time thinking about these issues.
      It is true that, as you say, there is a lack of imagination and vision about sequencing environments. But that is not at all the bottleneck of the current state of development. The bottleneck is much more practical: the lack of technical skill, good libraries, facilities, management, etc etc, in general: the lack of means to make it happen.
      On paper (have a look for example at the Logic manual or the Reaktor advertisements) everything is perfect, but the products are all shabby (i.e. full of bugs, inconsistencies, interface design flaws, etc). And we're not even talking about new, intuitive, 3D, flexible event spaces, and all the other beautiful things that come to mind when we forget for a moment that someone has to program it.
      As I see it, 'we' are still not capable of producing even the most straightforward interface for putting events in a row and playing them in a way that works. Before investing in new concept developers, appearantly we'll have to invest in technicians first.
      Yeah, you triggered me there :p Mattijs
      Quote: jbm wrote on Thu, 18 January 2007 11:57 ---------------------------------------------------- > Lately, I've been kind of obsessed with the idea of new sequencing paradigms. Sequencing GUIs are just so boring to me, these days; so flat, so musically vague. Ableton Live is kind of interesting, but somewhat limited in use, as is something like Sonasphere. What I'd be curious to see is a real 3D "world" type of paradigm. A space in which events are objects with form, colour, texture, and substance, and in which events visually show their relationships. Maybe offering various "views" on the sequence, prioritizing different notions of organization and relationship. I mean, in a program like Logic we've got a standard timeline, (crappy) score, piano scroll, and text-based event lists, but all of these paradigms are essentially unrelated to one another, visually speaking. The interface actually communicates very little about the relationships between events. (Okay, the piano scroll has a general metaphor of up/down for pitch and left/right/length for time/duration, but these are quite limited ways of visualizing music). > > There are visual metaphors that could actually communicate something about auditory relationships -- like transparency or size mapping to amplitude, in which case one could actually *see* the notion of masking. Or using fog for audio event boundaries, thus communicating the notion of sound dissipation or the effects of proximity on amplitude (also, crossfades and mixing). Or, conversely, using planes or "walls" to specify abrupt boundaries for audio events. Or texture for... well... texture. You get the idea. Of course, there are a vast number of possibilites, and problems with every one, I'm sure. But it often seems to me that all imagination around the visual representation of musical concepts in software dried up sometime in the '90s. Am I wrong? > > Of course, I'm not taking anything away from the ice tools. Not to mention the fact that all this visual stuff would eat CPU cycles for breakfast (though I guess a lot of it could be done on the graphics card). Mostly I'm just blabbing. I'm actually very curious about the ice tools, and will certainly keep my ear to the ground for more information, user experiences, and so on. > > J. ----------------------------------------------------
    • Jan 18 2007 | 12:43 pm
      Should have been does NOT work.
      On 1/17/07 7:07 PM, "Gary Lee Nelson" wrote:
      > Sorry if I confused things. I only mentioned detonate because, like > timeline, it does work as described. Gave up on in almost a year ago. > >
    • Jan 18 2007 | 1:42 pm
      On 18-Jan-2007, at 10:57, jbmaxwell wrote:
      > Lately, I've been kind of obsessed with the idea of new sequencing > paradigms.
      There should be lots and lots more paradigms. I got frustrated with the tape recorder-paradigm that was ubiquitous among 80s software sequencers and when Max came along I thought I would never look at a sequencer again. Then Anthony Bisset came by and pitched an idea to me.-)
      What I really wanted to say here is that Bill Buxton was doing creative thinking about ways to represent music, much back in the 80s. The focus was on score editing tools called SSSP, but lots of ideas and looking at music from different angles. You might want to Google on William Buxton SSSP, or try Google Scholar for more information.
      -- P.
      -------------- http://www.bek.no/~pcastine/Litter/ ------------- Peter Castine +--> Litter Power & Litter Bundle for Jitter Universal Binaries on the way iCE: Sequencing, Recording & Interface Building for |home | chez nous| Max/MSP Extremely cool |bei uns | i nostri| http://www.dspaudio.com/ http://www.castine.de
    • Jan 18 2007 | 2:18 pm
      Quote: Mattijs wrote on Thu, 18 January 2007 12:31 ---------------------------------------------------- > I share your obsession. In fact I am currently programming a visual sequencer interface for myself -and- turning logic inside out to link it to max, which is why I spend a lot of time thinking about these issues.
      ..that means you are not satisfied with seq/timeline/detonate too :) maybe you could get some of the $$ (i was down for the 50$ too!) finding the way to embed it in the max Api!!
    • Jan 18 2007 | 2:50 pm
      > What I really wanted to say here is that Bill Buxton was doing > creative thinking about ways to represent music, much back in the > 80s. The focus was on score editing tools called SSSP, but lots of > ideas and looking at music from different angles. You might want to > Google on William Buxton SSSP, or try Google Scholar for more > information. > > -- P. >
      Nice! Thanks, Peter. Just checking him out now.
      J.
    • Jan 18 2007 | 3:09 pm
    • Jan 18 2007 | 4:13 pm
      Mattijs Kneppers wrote: > I don't agree with you on this. A complete visual sequencing solution > is in fact a sequencer. Anything short of that would not be usable in > a sensible way, so isn't worth making.
      Hi Mattjis,
      I don't agree with you on this, a sequencer is much less than a timeline. And a timeline is more than sequencing events. If the available sequencers and DAWs would deliver what at least some wanted, this discussion would be less hot. The same applies actualy to notation. If the existing notation programs would deliver what is extending the common way of thinking and thus the common way of composing, all could be (almost) happy, there is always a way to connect different tools...
      But they don't, and thus for me and a lot of others on the list, the most appealing idea is to bring it into Max, but its a huge effort, on that I do agree, but before we need technicians, we need to open up our own imagination, elswise these technicians will just creat the same as before and put just a little bit more hype spice onto it...
      As you pointed out later: there is a lack of imagination what a timeline could be...
      I believe technically it would be built around a database for events (points in time) and gestures (spaced, spread in time). And in addition with a library for the visualisation/manipulation of the data. It needs both...
      I look forward what you'll come up with...
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Jan 18 2007 | 4:49 pm
      I know I started this but all I really wanted to do was time sequence messages with the ability to cut/paste, duplicate and drag to set action time and priority.
      This morning I took a completely different approach. I am using message boxes in a max patch that is saved as text. I have written an abstraction that parses the text file, pulls out the message objects, uses the horizontal and vertical position to set time and priority. I put together a preliminary package with an example. If anyone wants to look at this, contact me off list and I'll send you an archive with everything to make it work. (I assume the list still prohibits attachments.)
      Please send comments and suggestions.
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson
    • Jan 18 2007 | 5:00 pm
      > Hi Mattjis, > > I don't agree with you on this, a sequencer is much less than a > timeline. And a timeline is more than sequencing events.
      Ah, I think this must be a miscommunication. When I say sequencer I mean it in the most literatal way: putting things in a sequence. For me the word definitly doesn't refer to discrete steps, quantizing of any kind or any other limitation in continuity of time. Events can be anything, anchor-points of bezier curves if you want, depending on what you'll do with the info.
      For example my sequencer currently supports an infinite zooming level and infinite small steps (I really don't know why any sequencer wouldn't, even technically speaking), which is equal to a continuous timeline. As pointed out earlier in this thread, the limitation of other software to 'notes' and 'controllers' is silly as well. Who says my synths are going to interpret all sequenced info in this two catagories?
      But most of all, as I tried to state earlier, I am perfectly aware of the fact that whole teams of people didn't achieve to make a working solution (without bugs and inconsistencies to start with), while working for years. Of course I am a genius (*ahum* :p ), but anyway I prefer a bugfree piece of software over any feature or interface fancyness. That's why I work hard to upgrade my technical skills and knowledge first, -before- starting to dream about all the supersets of interface features that I could come up with. Even if I would end up, by lack of imagination, with another Logic but without the bugs/unlogicalness/general crap, I'd be quite happy.
      > I look forward what you'll come up with...
      Well.. no matter how much I would love to bore you with my current results, I won't. It will take at least another year before I get to the first real prototype (assuming in the mean time I get to work parttime for half a year or so). Of course I would be happy to invite someone as critical as you to do some prototype testing. And then I hope you'll completely burn down the concept and send me an endless stream of bugreports. I'd hate it to be another useless attempt.. ;)
      Cheers, Mattijs
      Quote: Stefan Tiedje wrote on Thu, 18 January 2007 17:13 ---------------------------------------------------- > Mattijs Kneppers wrote: > > I don't agree with you on this. A complete visual sequencing solution > > is in fact a sequencer. Anything short of that would not be usable in > > a sensible way, so isn't worth making. > > Hi Mattjis, > > I don't agree with you on this, a sequencer is much less than a > timeline. And a timeline is more than sequencing events. If the > available sequencers and DAWs would deliver what at least some wanted, > this discussion would be less hot. The same applies actualy to notation. > If the existing notation programs would deliver what is extending the > common way of thinking and thus the common way of composing, all could > be (almost) happy, there is always a way to connect different tools... > > But they don't, and thus for me and a lot of others on the list, the > most appealing idea is to bring it into Max, but its a huge effort, on > that I do agree, but before we need technicians, we need to open up our > own imagination, elswise these technicians will just creat the same as > before and put just a little bit more hype spice onto it... > > As you pointed out later: there is a lack of imagination what a timeline > could be... > > I believe technically it would be built around a database for events > (points in time) and gestures (spaced, spread in time). And in addition > with a library for the visualisation/manipulation of the data. It needs > both... > > I look forward what you'll come up with... > > Stefan > > -- > Stefan Tiedje------------x------- > --_____-----------|-------------- > --(_|_ ----|-----|-----()------- > -- _|_)----|-----()-------------- > ----------()--------www.ccmix.com > > ----------------------------------------------------
    • Jan 18 2007 | 5:02 pm
      > If the existing notation programs would deliver what is extending the > common way of thinking and thus the common way of composing, all could > be (almost) happy, there is always a way to connect different tools... >
      oooh, yes! I'm always terribly frustrated with notation apps. I've been bouncing back and forth between Finale and Sibelius for years. And I've mentioned more than once how happy I'd be if ENP (from PWGL) were given OSC capabilities, so we could use it in Max. There are ideas which come to me only through score, and I always miss those ideas when I work entirely without it.
      That said, I think my dream sequencer would be much more holistic. It would definitely have a score view, and selectable notation-based views of individual sequences, but that would be a music-visualization option, for dealing with the textual level of the music -- the nuts and bolts of notes and rhythms (when required). Beyond that, the environment would be much more... uh... synesthetic(?) On the other hand, it would also probably have a command line! ;-)
      I don't suppose we could get a group of people together to hash out some of these ideas, and maybe write some code -- off-list, of course, to spare everyone the misery.
      J.
    • Jan 18 2007 | 5:09 pm
      That's why I work hard to upgrade my technical skills and knowledge first, -before- starting to dream about all the supersets of interface features that I could come up with. Even if I would end up, by lack of imagination, with another Logic but without the bugs/unlogicalness/general crap, I'd be quite happy.
      Speaking of which, a rumor just bubbled up about Logic 8 rearing its head at NAMM tomorrow. Probably absolute crap, but you never know... and we are due for an upgrade.
      J.
    • Jan 18 2007 | 5:39 pm
      Hello Mattijs,
      I've been a Max user for almost 17 years, so believe me, I know what I'm talking about. I'm not looking for an integrated solutions such as Logic, Live or Cubase, which, incidentally, lack the ability to sequence symbolic messages and lists (I'd grateful if you could name such a software). And as a matter of fact, there is an existing solution in Max (i.e. timeline) which I'd actually prefer if it weren't so buggy. I always opted for a new version of timeline with tight integration with the pattr system and was hoping to create the necessary momentum for it on this list. I'm going to look into Peter Castine's iCE solution. If it does what I'm looking for, I'll let you all know.
      Best,
      Georg
      On Jan 17, 2007, at 7:18 PM, Mattijs Kneppers wrote:
      > > Quote: Georg Hajdu wrote on Wed, 17 January 2007 18:27 > ---------------------------------------------------- >> Hi Nathan, >> >> I appreciated your example. My comments were less directed at you as >> they were at Cycling '74; once again stressing the need of a visual >> sequencing solution. I hope you didn't misunderstand my intentions. > > Hi Georg, > > I don't agree with you on this. A complete visual sequencing > solution is in fact a sequencer. Anything short of that would not > be usable in a sensible way, so isn't worth making. > > To make a real sequencer takes enough time and effort to call it a > separate product (such as Logic, Cubase, Live, etc). If Cycling '74 > came to release a separate sequencer, I would probably be the first > one to buy it and pay an amount of money separate from the 850,- > that I paid for Max. > > In short, if you need to sequence events in Max, use an existing > sequencer tool. Looking at the various options available to link > max to other software, I'd say that is a very real option. > > Cheers, > Mattijs > >> Georg >> >> On Jan 17, 2007, at 2:08 PM, Nathan Wolek wrote: >> >>> On Jan 17, 2007, at 1:35 AM, Georg Hajdu wrote: >>>> It would be nice to use a visual paradigm. For interactive work, >>>> it's always nicer to know what's inside that box. >>> >>> I agree! but I was just showing how one can currently deploy the a >>> limited method of automatic preset changes for [pattrstorage]. >>> >>> I hope my use of "simple" was not misinterpreted to mean that this >>> is "easy to do already". It was a comment on the level of >>> functionality. "simple" = limited, basic, etc. >>> >>> --Nathan >>> >> >> > ---------------------------------------------------- > > > -- > SmadSteck - http://www.smadsteck.nl > Interactive audiovisual sampling soft- and hardware >
    • Jan 18 2007 | 5:48 pm
      Stefan,
      UPIC as a standalone timeline already exists. There was a recent announcement on the list. The software is called IanniX and looks pretty good in its recent iteration. It has a wonderful innovative interface and can be connected to Max via OSC. Unfortunately, it lacks the ability to sequence symbols and lists, which makes it much less interesting to me personally. But, who knows, they might even add this feature sometime in the future.
      Georg
      On Jan 17, 2007, at 11:45 PM, Stefan Tiedje wrote:
      > Gary Lee Nelson wrote: >> Am I missing something. timeline and detonate come with Max/MSP. >> Shouldn't >> they work already? > > The thread subject is still valid... > > But to dream on: I'd like to go beyond classic sequencers. As a > sequencer is defined as a sequence of events. But in favor of the > way of thinking of Xenakis, there is a demand for the continuum. > (The word timeline would still fit, a sequencer would be a step > back... > > I guess I have to do it, the ultimate successor of the UPIC as > Maxpatch... Any Bounties for that??? ;-) > > Stefan > > -- > Stefan Tiedje------------x------- > --_____-----------|-------------- > --(_|_ ----|-----|-----()------- > -- _|_)----|-----()-------------- > ----------()--------www.ccmix.com >
    • Jan 18 2007 | 6:02 pm
      Look at iTunes' 3D view, or browsing on the new iPhone. The concepts are there, the software is there (OpenGL), but someone actually needs to do the work. If I were 15 years younger and had time and money, I'd probably brave it.
      Georg
      On Jan 18, 2007, at 10:57 AM, jbmaxwell wrote:
      > But it often seems to me that all imagination around the visual > representation of musical concepts in software dried up sometime in > the '90s. Am I wrong?
    • Jan 18 2007 | 9:01 pm
    • Jan 18 2007 | 11:04 pm
      vade wrote on Thu, 18 January 2007 22:21 ---------------------------------------------------- > Data structures in PD are very nice, yes - take a look at this > piece by Hans Christoph Steiner for those who are unfamiliar: > it gives a good overview for one particular approach to scoring, > but data structures can map to anything. > > http://at.or.at/hans/solitude/
      About the graphic approach, it remembers me some scores of Ligeti, Stockhausen, etc. Is it a graphic rendering only or an interactive interface?
      Bye, Phil
    • Jan 18 2007 | 11:27 pm
      Interactive. can be updated and manipulated in realtime based on arbitrary input.
      I havent had firsthand experience with using it(PD has been notorously unreliable on my system), but Hans showed me some things, and I was quite impressed. There are some example patching of doing some silly things with datastructs on the PD list demonstrating some of its capabilities.
      On Jan 18, 2007, at 6:04 PM, Philippe Gruchet wrote:
      > > vade wrote on Thu, 18 January 2007 22:21 > ---------------------------------------------------- >> Data structures in PD are very nice, yes - take a look at this >> piece by Hans Christoph Steiner for those who are unfamiliar: >> it gives a good overview for one particular approach to scoring, >> but data structures can map to anything. >> >> http://at.or.at/hans/solitude/ > > About the graphic approach, it remembers me some scores of Ligeti, > Stockhausen, etc. > Is it a graphic rendering only or an interactive interface? > > Bye, > Phil
      v a d e //
      www.vade.info abstrakt.vade.info
    • Jan 18 2007 | 11:58 pm
      Quote: vade wrote on Fri, 19 January 2007 00:27 ---------------------------------------------------- > Interactive. can be updated and manipulated in realtime based > on arbitrary input.
      Seems great, indeed. A video would be very interesting.
    • Jan 19 2007 | 7:42 am
      Georg Hajdu wrote: > UPIC as a standalone timeline already exists. There was a recent > announcement on the list. The software is called IanniX and looks > pretty good in its recent iteration. It has a wonderful innovative > interface and can be connected to Max via OSC. Unfortunately, it lacks > the ability to sequence symbols and lists, which makes it much less > interesting to me personally. But, who knows, they might even add this > feature sometime in the future.
      Yes, I had a look at it, but as someone who has access to the real ancient UPIC, it had always been a bit of a disapointment and is really something very different. The first versions had no documentation at all. I looked at it, try to do something (out of my limited view how I believe it should work out of my experience with UPIC), it doesn't, I look for docs - ah now they are there and it looks definitely interesting, though lacking the most important strength of the UPIC: Juast draw the score...
      To make it actually sound you have to do a lot of programming around. You would actually need to combine it with some other storage parts in a Max patch. This is not only true for arbitrary messages, its also true for synthesis. It would make not a too big difference if you'd define the message in Max or in IanniX. Another lack compared to the original: You can't just copy paste a sample wave form into a page as curve...
      In general you can put an unexperienced composer in front of the UPIC and you will get audible results pretty fast. This would never work with IanniX, though it seems to have less restrictions, you need to construct your compositions in advance, the composer would need a musical assistant to translate it into sound...
      I'd better keep my flame for another tool in Max going.... ;-) But definitely anybody concerned about a timeline should have a look at it, its inspireing...
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Jan 19 2007 | 8:14 am
    • Jan 19 2007 | 8:22 am
      I suggest the pot goes to Mikael Laurson with the obligation for him to implement OSC NOW!
      PWGL is something, guys... He already made 90% of the job.
      f.e
      ps: thanks, Kasper, for the links .-)
      f.e chanfrault | aka | personal computer music > >>>>>> http://www.personal-computer-music.com > >>>>>> |sublime music for a desperate people|
      Peter Castine wrote: > Gary (and others on Mac OS), > > You might want to look at iCE Tools as an alternative to timeline. > It's a different paradigm, but ice.lattice is (a) simple, (b) > reliable, and (c) stable. > > iCE Tools costs more than the $50 ante people have been positing in > this thread, but its price is, frankly, more realistic given the work > involved. As f.e has discovered, this sort of thing is not a trivial > task. To give you an idea of just how much work was involved, note > that ice.lattice needed almost 3 years development to market. > > I will respond to the question about availability for Windows in the > thread in which the question was explicitly asked ("iCE sequencer > opinions"). > > Best, > Peter > > On 8-Jan-2007, at 9:41, Gary Lee Nelson wrote: >> I would really like to use timeline but in the past it was so buggy >> that I >> gave up. This morning I tried it again assuming that it had been fixed. >> The very first thing I tried caused max to crash. > > -------------- http://www.bek.no/~pcastine/Litter/ ------------- > Peter Castine +--> Litter Power & Litter Bundle for Jitter > Universal Binaries on the way > iCE: Sequencing, Recording & > Interface Building for |home | chez nous| > Max/MSP Extremely cool |bei uns | i nostri| > http://www.dspaudio.com/ http://www.castine.de > > >
    • Jan 19 2007 | 8:51 am
      YES! I couldn't agree more, f.e..
      ENP in PWGL is a truly brilliant scoring package -- I'd even say it's better than Finale or Sibelius, in terms of raw musical power. If we had access to that in Max, we could certainly get a long way in terms of musical and textural scoring for Max. I think Max would probably become my primary composition environment if we had ENP. As it is, I'm bouncing around between Finale, Sibelius, Logic, and Live...
    • Jan 19 2007 | 10:46 am
    • Jan 19 2007 | 12:01 pm
      Hey All,
      I just heard from Mika, who wrote the ENP score editor in PWGL, and he mentioned that SDIF and OSC are both big requests from PWGL users right now. He also mentioned that their forum/mailing list would be the best place to post feature requests, so maybe we could help get the ball rolling on OSC support at least -- perhaps a little bribing could speed things up!
      If you're interested in helping out with the "push" to get OSC support, you can sign up here:
      If you don't know about PWGL and ENP, you should definitely check them out:
      cheers,
      J.
    • Jan 19 2007 | 3:36 pm
      Georg Hajdu wrote: > That's exactly what I suggested 2 years ago!! But you need to "unlock" > seq~ to get access to its stored content, and that probably requires a > substantial modification of the object.
      I agree, with a timeline there are two crucial aspects, one is storing data, that can be achieved already, the other is manipulating that stored data, and thats the tricky part, especially if you want graphical representation ala UPIC/IanniX...
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Jan 19 2007 | 4:14 pm
      > > I agree, with a timeline there are two crucial aspects, one is storing > data, that can be achieved already, the other is manipulating that > stored data, and thats the tricky part, especially if you want graphical > representation ala UPIC/IanniX... > > Stefan > > -- > Stefan Tiedje------------x------- > --_____-----------|-------------- > --(_|_ ----|-----|-----()------- > -- _|_)----|-----()-------------- > ----------()--------www.ccmix.com > > ----------------------------------------------------
      That's why I'm so excited about PWGL and ENP. From within PWGL you can edit any value in the graphical/scoring interfaces either algorithmically or with the mouse and keyboard. So with OSC support, we could not only send the graphical/score data to Max, but could also alter the graphical/score data from Max. So much potential for sweetness.
      J.
    • Jan 19 2007 | 11:16 pm
      I took a look at Iannix, pretty cool. I have been looking for something like it for a long time, looks very promising. I was wondering if any of you guys have used it in any compositions?
    • Jan 20 2007 | 8:02 am
      Hi,
      About a more 'traditional' score presentation, does anyone tried to bridge Max to LilyPond ? The rendering is beautiful! Free, multi-platform, and sourcecode available:
      TIA, Philippe
    • Jan 20 2007 | 9:49 am
      What about IRIN ?
      I like it very much and it's written in Max/Msp.
      All the best
      Alessandro Fogar
    • Jan 20 2007 | 10:54 am
      ... and go back to the times where prehistoric men where typing
      key a major time 6/8 cis''8. d''16 cis''8 e''4 e''8 b'8. cis''16 b'8 d''4 d''8
      on their stone keyboards to keep a trace of their war chants ?!
      f.e
      f.e chanfrault | aka | personal computer music > >>>>>> http://www.personal-computer-music.com > >>>>>> |sublime music for a desperate people|
      Philippe Gruchet wrote: > Hi, > > About a more 'traditional' score presentation, does anyone tried to bridge Max to LilyPond ? > The rendering is beautiful! > Free, multi-platform, and sourcecode available: > > http://lilypond.org/web/index.html > > > TIA, > Philippe > >
    • Jan 20 2007 | 11:29 am
      f.e wrote on Sat, 20 January 2007 11:54 ---------------------------------------------------- > ... and go back to the times where prehistoric men where typing > > key a major > time 6/8 > cis''8. d''16 cis''8 e''4 e''8 > b'8. cis''16 b'8 d''4 d''8 > > on their stone keyboards to keep a trace of their war chants ?! ----------------------------------------------------
      Sarcastic? I can be sarcastic too. For graphic renderings, did you never used "POV Ray" or some other tools like that in the Unix world? No? Really?? Ahhh, 'prehistoric push-button' software only... :-) Lilypond is free, well-written, and I 'm just asking *in this very particular thread* if someone did the job for Max. Or if someone plans to do it.
      Bah-Bye, Philippe
    • Jan 20 2007 | 12:48 pm
      Actually, I agree that it would be great if some of these text-based notation apps could integrate directly into Max (read: OSC support), so we could render scores, in at least quasi-realtime, using a more rhythmically concise language. Outputting midi files is generally crap, since most notation apps interpret midi very poorly... unless your music is all totally quantized and uses simple metrical values only (maybe triplets, in a push). With something like LilyPond or, dare I say, ENP/PWGL, we could format the musical data coming out of Max into the precise notation we desired. That would be very cool. (As an example, it seems to me that Essl's group-rhythm uses the same basic rhythmic conventions as ENP notation.)
      Since this is all hypothetical anyway, I'm sticking with my fanatical obsession with ENP. It's just too good. But I suppose it may be possible to at least output ENP-readable text files from Max as is... I'll have to look into that.
      J.
    • Jan 20 2007 | 1:42 pm
      I agree with Philippe, I think. Anyway, as they say in stone age Washington, I rise to speak in favor of text-based systems.
      One of the best things the designers of max did was to provide a text version of patches. How else would we share them on this list? Many times I have found it useful to edit those files directly. Without these files I would still be wondering what max scripting is all about. And regexp - I still don't get it but. Like spinach, I know it's good for me.
      And XML...what a wordy but brilliant idea. Using music XML I can easily move between Sibelius and Finale to take advantage of the strengths of each. Someday, when music XML settles down, I plan to make some algorithmic pieces directly in XML for notation.
      In the dark ages of max - the 90's - we had pyrite from James McCartney who later gave us supercollider - both text systems. We communicate between max and supercollider with OSC - another text system.
      People have integrated csound, rtcmix, maxlisp and other text systems into max do to mention the brilliance of including java and openGL. And how to we write new externals? All together class...
      The list can go on for a very long time but I must include Peter Stone's Symbolic Composer and David Cope's work. Both use Lisp.
      Personally, I am fond of APL. Just bought the OSX update. I still use APL for things I cannot do easily in max like creating creating complex tables, funbuffs and colls - all text. Recently, I used APL to create a collection that included all inversions, voicing and voice leading among chords made from hexachords with the following characteristics:
      hexachord does not contain a tritone (there are six of them) no interval duplication between adjacent notes in the voicing larger intervals (> 7 semitones) on the bottom of the voicing
      And for voice leading
      compare all voicings in all transpositions to find number of tones and number of "held" notes between adjacent chord. sort progressions by "complexity" how much changes from chord to chord store the result in a coll that functions as a markov chain in max
      This was done in less than 100 lines of, er, APL text. Here' my one-liner for computing the serial matrix R of a tone row R. Order of execution is right-to-left.
      M = matrixtranspose 12 abs R outerproduct R = minus 1 take R
      Sorry about the formatting. APL uses its own TEXT font that cannot be emailed. (That's another rant.)
      On 1/20/07 6:29 AM, "Philippe Gruchet" wrote:
      > > f.e wrote on Sat, 20 January 2007 11:54 > ---------------------------------------------------- >> ... and go back to the times where prehistoric men where typing >> >> key a major >> time 6/8 >> cis''8. d''16 cis''8 e''4 e''8 >> b'8. cis''16 b'8 d''4 d''8 >> >> on their stone keyboards to keep a trace of their war chants ?! > ---------------------------------------------------- > > Sarcastic? I can be sarcastic too. > For graphic renderings, did you never used "POV Ray" or some other tools like > that in the Unix world? > No? Really?? Ahhh, 'prehistoric push-button' software only... > :-) > Lilypond is free, well-written, and I 'm just asking *in this very particular > thread* if someone did the job for Max. > Or if someone plans to do it. > > Bah-Bye, > Philippe
    • Jan 20 2007 | 3:05 pm
      jbm wrote on Sat, 20 January 2007 13:48 ---------------------------------------------------- > it would be great if some of these text-based > notation apps could integrate directly into Max
      Integration... I'd prefer an 'inter-application communication': a bridge.
      > we could format the musical data coming out of Max into the > precise notation we desired.
      YES, the user choice!
      > Since this is all hypothetical anyway
      Some people are dreaming about the future, some others are creating the future. I don't care about all others! A bridge with Lilypond could be done next week, and in a week.
      My buzz ;-) Philippe
    • Jan 20 2007 | 3:24 pm
      Quote: Philippe Gruchet wrote on Sat, 20 January 2007 15:05 ---------------------------------------------------- > jbm wrote on Sat, 20 January 2007 13:48 > ---------------------------------------------------- > > it would be great if some of these text-based > > notation apps could integrate directly into Max > > Integration... I'd prefer an 'inter-application communication': a bridge. >
      Yeah, that would be fine. But the only problem with LilyPond is that it's really just music notation, isn't it? Can it be used to create/display arbitrary messages, gestures, etc.?
      > > we could format the musical data coming out of Max into the > > precise notation we desired. > > YES, the user choice! > > > > Since this is all hypothetical anyway > > Some people are dreaming about the future, some others are creating the future. > I don't care about all others! > A bridge with Lilypond could be done next week, and in a week. >
      If it can be done in a week then why hasn't it been done? Just from a lack of interest? I'm confused... Also, are you thinking this "bridge" would be two-way? I guess I don't quite understand what LilyPond can transmit *back* to Max. I though it was basically just music typesetting -- really high-quality typesetting, but typesetting nonetheless. Am I wrong? Maybe you could clarify what you're thinking, and how it might be done.
      cheers,
      J.
    • Jan 20 2007 | 3:39 pm
    • Jan 20 2007 | 4:16 pm
      jbm wrote on Sat, 20 January 2007 16:24 ---------------------------------------------------- > If it can be done in a week then why hasn't it been done? > Just from a lack of interest?
      It's probably difficult to write a program without being paid for. However:
      > are you thinking this "bridge" would be two-way?
      Lilypond is a graphic rendering application *only*. Reason why I asked in a previous post about Data structures in PD if it was 'a graphic rendering only or an interactive interface'. Further, I don't have any kind of competency to really contribute on this topic. I was just asking for Lilypond.
      Best ;-) Philippe
    • Jan 20 2007 | 4:16 pm
      Here is a quick excerpt of what could be a larger patcher-scripting- event-based sequencer (adding graphic rulers, tracks, auto-patcher scrolling, etc. isn't very difficult - just needs time). By working with send/receives, you could virtually have any number of synchronized/predictive/whatever sequencers
      Just save the patch and open it once, so loadbangs can be effective :
    • Jan 20 2007 | 4:44 pm
      jmdarremont wrote on Sat, 20 January 2007 16:39 ---------------------------------------------------- > exporting a midifile then editing it in a MIDI sequencer (DP, > Logic, SX ...) is still much more interesting, creatively.
      Probably... not for me ;-) I'm a 'musical instruments player', not a 'notator', and really tired about MIDI.
      > I didn't find it very useful unless you need a special > notation which is not handled by other softwares.
      That's my case, for complex tuplets and metric modulations. And then, up to something like !!! I'd say, all possible kind of timelines would be great to explore as *tools for musicians* :-)
      Bye, Philippe
    • Jan 20 2007 | 9:59 pm
      Cher Manuel,
      I couldn't resist having a look through your patch. It was haunting me all afternoon. I love it! Everyone interested in this thread should have a look
      It is a much better solution than anything I came up with. I had a sense that something in java would be the key (text isn't it?). You are treating a max patch as a data structure. Exactly where I was going. It does everything that timeline does and more plus it is much more intuitive. I tried running multiple instances and it works great. Will also work nicely with pattr.
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson
      On 1/20/07 11:16 AM, "Manuel Poletti" wrote:
      > Here is a quick excerpt of what could be a larger patcher-scripting- > event-based sequencer (adding graphic rulers, tracks, auto-patcher > scrolling, etc. isn't very difficult - just needs time). By working > with send/receives, you could virtually have any number of > synchronized/predictive/whatever sequencers
    • Jan 20 2007 | 10:20 pm
    • Jan 20 2007 | 10:57 pm
      Manuel,
      Thank you for this elegant solution. I am humbled (not unusual when visiting here).
      --raf
      Manuel Poletti wrote: > [. . .] > #P newex 83 256 96 196617 js patchdescribe.js; > [. . .]
    • Jan 21 2007 | 1:30 am
      Oops...I found a bug. If you make the patch wider and then use use the scroll bars to move around in the window, the cursor gets out of sync since the objects are positioned relative to the left side of the visible part of the patch. Obeject out of view to the left have negative positions. Banging patcherscribe resyncs but what if the bang message is out of sight. I've noticed an origin message in the text files of patchers that have been saved with the scroll bar moved. It gives the horizonal and vertical offsets. Perhaps your .js can sense when the scroll bars are moved and bang automatically. For the time being, I am using the enter key to bang patcherscribe.
      On 1/20/07 11:16 AM, "Manuel Poletti" wrote:
      > Here is a quick excerpt of what could be a larger patcher-scripting- > event-based sequencer (adding graphic rulers, tracks, auto-patcher > scrolling, etc. isn't very difficult - just needs time). By working > with send/receives, you could virtually have any number of > synchronized/predictive/whatever sequencers
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson
    • Jan 21 2007 | 2:30 am
      Yeah, that is really great! I definitely had a lot of food for thought after figuring out your technique. Just another example that there's so many other ways to do things in Max that I don't know about.... it makes sense when I see it done, but would never have come up with it on my own.
      I imagine a user-controllable playback area would be great for scrubbing, automation, looping, etc... like you said, this is an example only.
      One question--if one wanted to use a different event than a button, say a horizontal panel or something, I was able to do this OK, but how might you allow multiple "hits" on the object, rather than just one when the cursor first encounters the object? So, for example, there'a a panel about 100 pixels wide, and when it gets run over by the cursor, it accesses a table (or something) based upon where the cursor is over it. Depending on speed there might be a hundred accesses, or lots fewer. Also, the cursor would play the object when going backwards, as yours doesn't seem to.
      I also notice there's no metro to speak of (I was just sure there had to be one somewhere!)... I had always envisioned determining speed based upon pixels and a metro, but this seems to work much better (and I know metro isn't the stablest). However, the idea would be the same with a phasor~, too---i.e., how long does one stay at each pixel point, and how many pixels are the jumps from one to the next (could be fractional amounts). This paradigm would take object sizes/widths into account during playback, which would be beneficial.
      Not to mention that a large LCD could then be accessed based upon pixel coordinates... there's your graphical score editor!
      -C
    • Jan 21 2007 | 2:31 am
      While I am *very* impressed with this patch on a programmtical level, I can forsee using it with any sort of high cpu load. I just tried it with my performance patch, just running the timeline as is in the background, and it killed my framerate, even on a core 2 duo machine.
      Not trying to be a buzzkill, its a really nice approach - I bet with some tweaking it could be made more efficient, but its certainly not an end all answer I dont think.
      On Jan 20, 2007, at 5:57 PM, Robert Albert Falesch wrote:
      > Manuel, > > Thank you for this elegant solution. I am humbled (not unusual when > visiting here). > > --raf > > Manuel Poletti wrote: >> [. . .] >> #P newex 83 256 96 196617 js patchdescribe.js; >> [. . .]
      v a d e //
      www.vade.info abstrakt.vade.info
    • Jan 21 2007 | 9:13 am
      I'd like to announce that there are plans to integrate JMSL more tightly into MaxMSP. Features will also include the ability to enter and edit music events from MaxMSP and to draw the score to LCD. JMSL has MusicXML and Lilypond export which makes it a great bridge to other notation environments. Please write me off-list if you have more questions.
      Georg
      On Jan 20, 2007, at 5:45 PM, Philippe Gruchet wrote:
      > > jmdarremont wrote on Sat, 20 January 2007 16:39 > ---------------------------------------------------- >> exporting a midifile then editing it in a MIDI sequencer (DP, >> Logic, SX ...) is still much more interesting, creatively. > > Probably... not for me ;-) > I'm a 'musical instruments player', not a 'notator', and really > tired about MIDI. > >> I didn't find it very useful unless you need a special >> notation which is not handled by other softwares. > > That's my case, for complex tuplets and metric modulations. > And then, up to something like !!! > I'd say, all possible kind of timelines would be great to explore > as *tools for musicians* :-) > > Bye, > Philippe > > PS: I'm now supporting another project and won't have any fund for > this one before an 'uncertain amount of time'. >
    • Jan 21 2007 | 10:34 am
      That is a *very* cool patch, Manuel! A great and imaginative use of what Max has to offer.
      Unfortunately, I just can't get excited about JMSL. Maybe the examples of notation don't do the platform justice, but they seem clunky to me. Am I wrong? The score interface looks like some old OS 8.1 app to me. For $120, it just doesn't seem like money well-spent, otherwise I would probably have bought a license by now. Mind you, if they actually *included* it in Max (i.e., gratis -- with the cost of upgrading), I would obviously take advantage of it. I'm just not "sold" on it as an add-on solution. If I were a java programmer *without* Max, on the other hand, it would be a different story. In that case the general power of the API, beyond notation, would be worth the cost of admission.
      J.
    • Jan 21 2007 | 11:58 am
      On 1/20/07 9:30 PM, "Seejay James" wrote:
      > > Yeah, that is really great! I definitely had a lot of food for thought after > figuring out your technique. Just another example that there's so many other > ways to do things in Max that I don't know about.... it makes sense when I see > it done, but would never have come up with it on my own. > > I imagine a user-controllable playback area would be great for scrubbing, > automation, looping, etc... like you said, this is an example only. > > One question--if one wanted to use a different event than a button, say a
      The .js looks at all of the objects in the patch and collects positions of all of the buttons. Any object that can be activated with a bang can be used but the button is a nice visual cue and you can use it to test an event out of sequence.
      > horizontal panel or something, I was able to do this OK, but how might you > allow multiple "hits" on the object, rather than just one when the cursor > first encounters the object? So, for example, there'a a panel about 100 pixels > wide, and when it gets run over by the cursor, it accesses a table (or > something) based upon where the cursor is over it. Depending on speed there > might be a hundred accesses, or lots fewer. Also, the cursor would play the > object when going backwards, as yours doesn't seem to. > > I also notice there's no metro to speak of (I was just sure there had to be > one somewhere!)... I had always envisioned determining speed based upon pixels
      Delays work on horizontal values in a coll.
      > and a metro, but this seems to work much better (and I know metro isn't the > stablest). However, the idea would be the same with a phasor~, too---i.e., how > long does one stay at each pixel point, and how many pixels are the jumps from > one to the next (could be fractional amounts). This paradigm would take object > sizes/widths into account during playback, which would be beneficial.
      Exactly!
      > Not to mention that a large LCD could then be accessed based upon pixel > coordinates... there's your graphical score editor!
      Yes, this works fine. You simply scan lcd getting pixels as you go. For each pixel you have x, y and color - numbers you can map into musical parameters. You can also do this with jit.matrix. I used this to implement a primitive MetaSynth-like capability in Max. > > -C
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson
    • Jan 21 2007 | 12:00 pm
      On 1/21/07 4:13 AM, "Georg Hajdu" wrote:
      > I'd like to announce that there are plans to integrate JMSL more > tightly into MaxMSP. > Features will also include the ability to enter and edit music events > from MaxMSP and to draw the score to LCD. > JMSL has MusicXML and Lilypond export which makes it a great bridge > to other notation environments. > Please write me off-list if you have more questions. > > Georg >
      Is there a link for more information?
      Cheers Gary Lee Nelson Oberlin College www.timara.oberlin.edu/GaryLeeNelson