o.display (was o.show) and PD anxieties

[adrianfreed]

For future research exploration we can explore scrolling history etc. Note that o.show has another important function (persistence) to catch brief messages. This may be hard to integrate into a scrolling history o.display.

For the 1.0 release we just need o.message 2nd outlet functionality correct pretty printing of sub bundles according to improvements going into o.message. flashing dot indicator of new message

[ilzxc]

The dot is already there in o.message (issue #21) - in C++ I use an std::vector to ensure that all bundles are stored in a contiguous memory block (see didl), but John's idea for an AVL Tree as an underlying structure for an o.table is the direction I'm investigating first.

If this isn't done by the middle of next week, would be wiser to hold this off until odot 2.0...

[adrianfreed]

please hold as many features and performance optimizations to 2.0

For 1.0 we want the minimimum kernel of the whiff of the essence of the object. Something with an interface design we wont regret later and can build on. We are going to run out of time to document and test well if we keep making things this interesting.

Also, w

On Jun 14, 2014, at 10:06 PM, ilya notifications@github.com wrote:

The dot is already there in o.message (issue #21) - in C++ I use an std::vector to ensure that all bundles are stored in a contiguous memory block (see didl), but John's idea for an AVL Tree as an underlying structure for an o.table is the direction I'm investigating first.

If this isn't done by the middle of next week, would be wiser to hold this off until odot 2.0...

— Reply to this email directly or view it on GitHub.

[adrianfreed]

o.display needs to save NO information with the patch to avoid dirtying patches and for it to make sense as a monitoring tool with Max Player On Jun 15, 2014, at 9:55 AM, Adrian Freed adrian@adrianfreed.com wrote:

please hold as many features and performance optimizations to 2.0

For 1.0 we want the minimimum kernel of the whiff of the essence of the object. Something with an interface design we wont regret later and can build on. We are going to run out of time to document and test well if we keep making things this interesting.

Also, w

On Jun 14, 2014, at 10:06 PM, ilya notifications@github.com wrote:

The dot is already there in o.message (issue #21) - in C++ I use an std::vector to ensure that all bundles are stored in a contiguous memory block (see didl), but John's idea for an AVL Tree as an underlying structure for an o.table is the direction I'm investigating first.

If this isn't done by the middle of next week, would be wiser to hold this off until odot 2.0...

— Reply to this email directly or view it on GitHub.

[ilzxc]

This just turned into a pretty concise spec! I've had good luck over the weekend compiling externals in C++, but I'm afraid that this may cause headaches for pd, and flext introduces unnecessary overhead. I'll implement the underlying data structure for the external ASAP, and will work out the visual side of things once the details of correct bundle-to-text output have been settled upon.

[adrianfreed]

To reiterate: o.display for the 1.0 release just has to have: a single inlet slightly different look and feel to o.message but the same (default) formatting that o.message uses no interaction (text input) with the box the same flashing "." as o.message. I recommend making minor mods to the o.message code to achieve this

[ilzxc]

I'm on it.

On Jun 20, 2014, at 9:33 AM, Adrian Freed notifications@github.com wrote:

To reiterate: o.display for the 1.0 release just has to have: a single inlet slightly different look and feel to o.message but the same (default) formatting that o.message uses no interaction (text input) with the box the same flashing "." as o.message. I recommend making minor mods to the o.message code to achieve this

— Reply to this email directly or view it on GitHub.

[adrianfreed]

I don't know that there is much mileage using flext for GUI objects as there is a bunch of tcl/tk to do. PD port is a Release 2.0 task.

On Jun 20, 2014, at 12:10 PM, ilya notifications@github.com wrote:

I'm on it.

On Jun 20, 2014, at 9:33 AM, Adrian Freed notifications@github.com wrote:

To reiterate: o.display for the 1.0 release just has to have: a single inlet slightly different look and feel to o.message but the same (default) formatting that o.message uses no interaction (text input) with the box the same flashing "." as o.message. I recommend making minor mods to the o.message code to achieve this

— Reply to this email directly or view it on GitHub. — Reply to this email directly or view it on GitHub.

[ilzxc]

I'd like to vote in favor of PD port being a 2.0 release. For now, there's no reason to use C++ for anything - rolling out our own structure for o.display's memory of things is the right thing to do. (I love C++, and I'll be using that for NODEjs/Node-RED port which I assume is also part of the 2.0 release.)

On Fri, Jun 20, 2014 at 1:11 PM, Adrian Freed notifications@github.com wrote:

I don't know that there is much mileage using flext for GUI objects as there is a bunch of tcl/tk to do. PD port is a Release 2.0 task.

On Jun 20, 2014, at 12:10 PM, ilya notifications@github.com wrote:

I'm on it.

On Jun 20, 2014, at 9:33 AM, Adrian Freed notifications@github.com wrote:

To reiterate: o.display for the 1.0 release just has to have: a single inlet slightly different look and feel to o.message but the same (default) formatting that o.message uses no interaction (text input) with the box the same flashing "." as o.message. I recommend making minor mods to the o.message code to achieve this

— Reply to this email directly or view it on GitHub. — Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/CNMAT/CNMAT-odot/issues/40#issuecomment-46721392.

[adrianfreed]

Yep, wrestling with portability is the primary aim of 2.0

Let's try not to put too many challenging things for this into 1.0

I have a quiet hope we can build a tool to export the Max abstractions automatically into PD - not a general tool but one that will work on 90% of our abstractions.

On Jun 20, 2014, at 1:55 PM, ilya notifications@github.com wrote:

I'd like to vote in favor of PD port being a 2.0 release. For now, there's no reason to use C++ for anything - rolling out our own structure for o.display's memory of things is the right thing to do. (I love C++, and I'll be using that for NODEjs/Node-RED port which I assume is also part of the 2.0 release.)

On Fri, Jun 20, 2014 at 1:11 PM, Adrian Freed notifications@github.com wrote:

I don't know that there is much mileage using flext for GUI objects as there is a bunch of tcl/tk to do. PD port is a Release 2.0 task.

On Jun 20, 2014, at 12:10 PM, ilya notifications@github.com wrote:

I'm on it.

On Jun 20, 2014, at 9:33 AM, Adrian Freed notifications@github.com wrote:

To reiterate: o.display for the 1.0 release just has to have: a single inlet slightly different look and feel to o.message but the same (default) formatting that o.message uses no interaction (text input) with the box the same flashing "." as o.message. I recommend making minor mods to the o.message code to achieve this

— Reply to this email directly or view it on GitHub. — Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/CNMAT/CNMAT-odot/issues/40#issuecomment-46721392.

— Reply to this email directly or view it on GitHub.

[ilzxc]

I still have a little thing I started in Python for max2pd, but I never got it going anywhere, but I should try again. The other way (pd2max) is a lot harder.

[adrianfreed]

I was going to suggest you use the logic in o.context (or in JS) to walk the graph in a patch and spit out the text form of a patch.

On Jun 20, 2014, at 10:27 PM, ilya notifications@github.com wrote:

I still have a little thing I started in Python for max2pd, but I never got it going anywhere, but I should try again. The other way (pd2max) is a lot harder.

— Reply to this email directly or view it on GitHub.

[ilzxc]

I'm not going to prioritize this, since there's a lot of work to do right now, but I'll give it a whirl for a bit just to see what would happen. I may rue this whirl, I may very well rue this whirl, indeed.

On Fri, Jun 20, 2014 at 10:29 PM, Adrian Freed notifications@github.com wrote:

I was going to suggest you use the logic in o.context (or in JS) to walk the graph in a patch and spit out the text form of a patch.

On Jun 20, 2014, at 10:27 PM, ilya notifications@github.com wrote:

I still have a little thing I started in Python for max2pd, but I never got it going anywhere, but I should try again. The other way (pd2max) is a lot harder.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/CNMAT/CNMAT-odot/issues/40#issuecomment-46745143.

[adrianfreed]

It's a good exercise to get an idea of how max/msp manages its parents and children and wiring

On Jun 20, 2014, at 11:09 PM, ilya notifications@github.com wrote:

I'm not going to prioritize this, since there's a lot of work to do right now, but I'll give it a whirl for a bit just to see what would happen. I may rue this whirl, I may very well rue this whirl, indeed.

On Fri, Jun 20, 2014 at 10:29 PM, Adrian Freed notifications@github.com wrote:

I was going to suggest you use the logic in o.context (or in JS) to walk the graph in a patch and spit out the text form of a patch.

On Jun 20, 2014, at 10:27 PM, ilya notifications@github.com wrote:

I still have a little thing I started in Python for max2pd, but I never got it going anywhere, but I should try again. The other way (pd2max) is a lot harder.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/CNMAT/CNMAT-odot/issues/40#issuecomment-46745143.

— Reply to this email directly or view it on GitHub.

[ilzxc]

So at the moment I have a basic 1-1 translator between Max and PD that does not support anything other than odot objects (so, no bangs, no toggles, no comments).

What it does do, however, is:

• creates a window that's the right size & positioned at the right place on the screen
• creates objects (including o.message objects) at the correct coordinates (and the correct width when it comes to odot messages)
• creates patch cords between objects, seemingly correctly for now (because python can be great sometimes)

So this is a solid beginning. I need to make sure that basics (bangs, messages, comments, and toggles) are correctly dealt with. But what's nice is that the coordinate systems are identical, pd patches are very easy to write in text and JSON is easy to parse.

I do not have the current pd build at the moment, so I have to make an extra step to find-and-replace "o." and change them to "o" before the output works with the alpha build from the CNMAT site. I'll throw it into /experimental/ and open an issue for it when it's doesn't fail miserably whenever it stumbles onto a button. If anyone (RAMA) has the most current pd build, that would be really appreciated.

On Fri, Jun 20, 2014 at 11:10 PM, Adrian Freed notifications@github.com wrote:

It's a good exercise to get an idea of how max/msp manages its parents and children and wiring

On Jun 20, 2014, at 11:09 PM, ilya notifications@github.com wrote:

I'm not going to prioritize this, since there's a lot of work to do right now, but I'll give it a whirl for a bit just to see what would happen. I may rue this whirl, I may very well rue this whirl, indeed.

On Fri, Jun 20, 2014 at 10:29 PM, Adrian Freed notifications@github.com

wrote:

I was going to suggest you use the logic in o.context (or in JS) to walk the graph in a patch and spit out the text form of a patch.

On Jun 20, 2014, at 10:27 PM, ilya notifications@github.com wrote:

I still have a little thing I started in Python for max2pd, but I never got it going anywhere, but I should try again. The other way (pd2max) is a lot harder.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/CNMAT/CNMAT-odot/issues/40#issuecomment-46745143.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/CNMAT/CNMAT-odot/issues/40#issuecomment-46745759.

[ilzxc]

https://github.com/CNMAT/CNMAT-odot/tree/master/experimental/max2pd

In /tests you can see that it successfully transcodes o.poissonprocess and o.was.

On Sat, Jun 21, 2014 at 1:54 AM, Ilya Y. Rostovtsev < ilyaforpresident@gmail.com> wrote:

So at the moment I have a basic 1-1 translator between Max and PD that does not support anything other than odot objects (so, no bangs, no toggles, no comments).

What it does do, however, is:

• creates a window that's the right size & positioned at the right place on the screen
• creates objects (including o.message objects) at the correct coordinates (and the correct width when it comes to odot messages)
• creates patch cords between objects, seemingly correctly for now (because python can be great sometimes)

So this is a solid beginning. I need to make sure that basics (bangs, messages, comments, and toggles) are correctly dealt with. But what's nice is that the coordinate systems are identical, pd patches are very easy to write in text and JSON is easy to parse.

I do not have the current pd build at the moment, so I have to make an extra step to find-and-replace "o." and change them to "o" before the output works with the alpha build from the CNMAT site. I'll throw it into /experimental/ and open an issue for it when it's doesn't fail miserably whenever it stumbles onto a button. If anyone (RAMA) has the most current pd build, that would be really appreciated.

On Fri, Jun 20, 2014 at 11:10 PM, Adrian Freed notifications@github.com wrote:

It's a good exercise to get an idea of how max/msp manages its parents and children and wiring

On Jun 20, 2014, at 11:09 PM, ilya notifications@github.com wrote:

I'm not going to prioritize this, since there's a lot of work to do right now, but I'll give it a whirl for a bit just to see what would happen. I may rue this whirl, I may very well rue this whirl, indeed.

On Fri, Jun 20, 2014 at 10:29 PM, Adrian Freed < notifications@github.com> wrote:

I was going to suggest you use the logic in o.context (or in JS) to walk the graph in a patch and spit out the text form of a patch.

On Jun 20, 2014, at 10:27 PM, ilya notifications@github.com wrote:

I still have a little thing I started in Python for max2pd, but I never got it going anywhere, but I should try again. The other way (pd2max) is a lot harder.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/CNMAT/CNMAT-odot/issues/40#issuecomment-46745143.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/CNMAT/CNMAT-odot/issues/40#issuecomment-46745759.

[adrianfreed]

Nice Work!

Should I put a PD release as part of 1.0 now?

On Jun 21, 2014, at 5:45 AM, ilya notifications@github.com wrote:

https://github.com/CNMAT/CNMAT-odot/tree/master/experimental/max2pd

In /tests you can see that it successfully transcodes o.poissonprocess and o.was.

On Sat, Jun 21, 2014 at 1:54 AM, Ilya Y. Rostovtsev < ilyaforpresident@gmail.com> wrote:

So at the moment I have a basic 1-1 translator between Max and PD that does not support anything other than odot objects (so, no bangs, no toggles, no comments).

What it does do, however, is:

• creates a window that's the right size & positioned at the right place on the screen
• creates objects (including o.message objects) at the correct coordinates (and the correct width when it comes to odot messages)
• creates patch cords between objects, seemingly correctly for now (because python can be great sometimes)

So this is a solid beginning. I need to make sure that basics (bangs, messages, comments, and toggles) are correctly dealt with. But what's nice is that the coordinate systems are identical, pd patches are very easy to write in text and JSON is easy to parse.

I do not have the current pd build at the moment, so I have to make an extra step to find-and-replace "o." and change them to "o" before the output works with the alpha build from the CNMAT site. I'll throw it into /experimental/ and open an issue for it when it's doesn't fail miserably whenever it stumbles onto a button. If anyone (RAMA) has the most current pd build, that would be really appreciated.

On Fri, Jun 20, 2014 at 11:10 PM, Adrian Freed notifications@github.com wrote:

It's a good exercise to get an idea of how max/msp manages its parents and children and wiring

On Jun 20, 2014, at 11:09 PM, ilya notifications@github.com wrote:

I'm not going to prioritize this, since there's a lot of work to do right now, but I'll give it a whirl for a bit just to see what would happen. I may rue this whirl, I may very well rue this whirl, indeed.

On Fri, Jun 20, 2014 at 10:29 PM, Adrian Freed < notifications@github.com> wrote:

I was going to suggest you use the logic in o.context (or in JS) to walk the graph in a patch and spit out the text form of a patch.

On Jun 20, 2014, at 10:27 PM, ilya notifications@github.com wrote:

I still have a little thing I started in Python for max2pd, but I never got it going anywhere, but I should try again. The other way (pd2max) is a lot harder.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/CNMAT/CNMAT-odot/issues/40#issuecomment-46745143.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/CNMAT/CNMAT-odot/issues/40#issuecomment-46745759.

— Reply to this email directly or view it on GitHub.

[ilzxc]

Not until I sort out subpatchers, but it is possible.

On Jun 21, 2014, at 7:48 AM, Adrian Freed notifications@github.com wrote:

Nice Work!

Should I put a PD release as part of 1.0 now?

On Jun 21, 2014, at 5:45 AM, ilya notifications@github.com wrote:

https://github.com/CNMAT/CNMAT-odot/tree/master/experimental/max2pd

In /tests you can see that it successfully transcodes o.poissonprocess and o.was.

On Sat, Jun 21, 2014 at 1:54 AM, Ilya Y. Rostovtsev < ilyaforpresident@gmail.com> wrote:

So at the moment I have a basic 1-1 translator between Max and PD that does not support anything other than odot objects (so, no bangs, no toggles, no comments).

What it does do, however, is:

• creates a window that's the right size & positioned at the right place on the screen
• creates objects (including o.message objects) at the correct coordinates (and the correct width when it comes to odot messages)
• creates patch cords between objects, seemingly correctly for now
  (because python can be great sometimes)

So this is a solid beginning. I need to make sure that basics (bangs, messages, comments, and toggles) are correctly dealt with. But what's nice is that the coordinate systems are identical, pd patches are very easy to write in text and JSON is easy to parse.

I do not have the current pd build at the moment, so I have to make an extra step to find-and-replace "o." and change them to "o" before the output works with the alpha build from the CNMAT site. I'll throw it into /experimental/ and open an issue for it when it's doesn't fail miserably whenever it stumbles onto a button. If anyone (RAMA) has the most current pd build, that would be really appreciated.

On Fri, Jun 20, 2014 at 11:10 PM, Adrian Freed notifications@github.com wrote:

It's a good exercise to get an idea of how max/msp manages its parents and children and wiring

On Jun 20, 2014, at 11:09 PM, ilya notifications@github.com wrote:

I'm not going to prioritize this, since there's a lot of work to do right now, but I'll give it a whirl for a bit just to see what would happen.
I may rue this whirl, I may very well rue this whirl, indeed.

On Fri, Jun 20, 2014 at 10:29 PM, Adrian Freed < notifications@github.com> wrote:

I was going to suggest you use the logic in o.context (or in JS) to walk the graph in a patch and spit out the text form of a patch.

On Jun 20, 2014, at 10:27 PM, ilya notifications@github.com wrote:

I still have a little thing I started in Python for max2pd, but I never got it going anywhere, but I should try again. The other way (pd2max) is a lot harder.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/CNMAT/CNMAT-odot/issues/40#issuecomment-46745143.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/CNMAT/CNMAT-odot/issues/40#issuecomment-46745759.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

[adrianfreed]

For what it is worth I suspect the need for subpatchers will go away in a lot of our patches as we make the more compact with the codeboxes

[ilzxc]

Subpatchers are taken care of now. I got John's mammoth o.io.bluetoothle thing to convert to puredata with subpatchers and everything. I'll need to build odot for pd on my machine for testing, but this is both checked in as well as shelved right now, becase SLIP & o.display are a-calling.

[ilzxc]

Also, again voting against pd in 1.0, because all of the GUI objects that we're creating for coding stuff properly will need to be tested adequately. Unless Rama can make the 1.0 deadlines for supporting the pd side of things, it's looking like John and I are going to be too busy with the Max release to do this right (and there's no point in doing it wrong).

So, pd in 2.0 and maybe my max2pd stuff will be useful - but I think I'm going to prioritize o.display and o.sliposc.

[adrianfreed]

I concur

On Jun 21, 2014, at 6:50 PM, ilya notifications@github.com wrote:

Also, again voting against pd in 1.0, because all of the GUI objects that we're creating for coding stuff properly will need to be tested adequately. Unless Rama can make the 1.0 deadlines for supporting the pd side of things, it's looking like John and I are going to be too busy with the Max release to do this right (and there's no point in doing it wrong).

So, pd in 2.0 and maybe my max2pd stuff will be useful - but I think I'm going to prioritize o.display and o.sliposc.

— Reply to this email directly or view it on GitHub.

[ramagottfried]

hey just saw this, can someone clue me in on what the 1.0 deadlines are? maybe try to send me notes from meetings etc.?

Also, can fill me in about these new GUI objects? "scrolling history" sounds amazing!

What is Max Player?

re: PD build, just run make and you should have it, it's in the pd_release_package/cnmat folder (don't forget to make sure you have the latest libomax built as well)

I took a quick look at the max2pd stuff last night, looking good so far. I was working on a pd version of o.helpfilehelper, but got a little slowed down with other work -- just parsing the json and transferring from max is a good workaround I think for help patches, and will save a lot of time. PD formatting is annoying, so if we use a translation script for the help patches we'll still need to open them all and make sure they look nice (... I'm not saying my help patches look nice right now! they were quickies).

Note: PD does not search subfolders, so all abstractions included in the release will need to be at the same folder level.

I'm fine with PD being in beta for longer until some more serious work is done with it, but it would be nice if it were somehow included in a release.

[adrianfreed]

You can see deadlines in the milestones tags of issues. We are waiting for a consensus on the GUI object design. Ilya is the lead on that. There are no meeting minutes. Speculations are circulating here and there in the issues. Max Player is thing that plays but doesn't allow you to edit Max patches. PD release is "later in summer". It would make sense for the 2.0 release of Max/MSP to include a PD release. It can't be done for the 1.0 release which we will use to teach the Max/MSP class in a couple of weeks.

[adrianfreed]

I have reopened and assigned this to 2.0 because of issues such as those raised with respect to PD's flat search problems.

[ramagottfried]

Hi, sorry, what's the flat search problem? I'm not sure if I know about this. do you mean the lack of searching subfolders?

[adrianfreed]

On Jul 1, 2014, at 11:53 AM, ramagottfried notifications@github.com wrote:

Hi, sorry, what's the flat search problem? I'm not sure if I know about this. do you mean the lack of searching subfolders? Yes