Nodebox2 beta
前几天在xindanwei遇到了一位玩openframework的朋友, 于是又燃起了我对于Processing和Nodebox的兴趣.
Nodebox即使在圈内也很少让人了解, 只能在Mac平台上运行或许的确会让人有距离感. 好消息是, Nodebox2正在努力支持Windows, 并且有可能非官方的支持Linux
非常有意思的是, Nodebox第一版本里使用的是OSX的python, 并且基于Cocoa的平台提供多媒体能力.
在第二版中, 似乎放弃了使用CPython的意图, 转而使用Jython.
猜测或许是因为Java平台提供了统一的多媒体接口, 而且Jython2.5也不再是beta状态了.
当然也许作者原本就擅长Java所以是Jython的用户. 当然这仅仅是我的猜测.
毕竟从作者的角度, 把opengl用python包装一遍并不是什么愉快的工作, java平台自己可能做的不错. 至少这里我们看到了又一个jython的经典案例.
在processing之外, 我们看到了一个支持动态数据类型的脚本的工具, 的确值得欣喜.
和使用openframework的朋友聊天, 看来在商业应用上, 似乎processing还是没有表现出足够的性能. 所以Nodebox和processing也仅仅作为prototype的工具, 还是相当不错的选择.
当然还有一些朋友讲了另外一个故事: 用C++写了一个不错的游戏, 分享给论坛的用户, 结果却是无人问津. EXE文件在当今这个时代确实是一个尴尬的东西, 除非你的产品很有名气, 否则用户不会轻易执行你的作品. jar在这方面倒是很有优势.
如果Nodebox将来可以编译成java applet, 也将是一件很有意思的事情.
最后从现在的beta本版的角度来看, Nodebox会加入一些可视编程的元素, 这也能体现Node的特性. 用户不再需要为问题写出通篇的程序, 而是通过串联一些特定的程序模块来解决问题. 这为程序员和艺术家之间的合作提供了不错的方案. 像Puredata/MaxMSP之类的工具, 如果可以更加融合一些通用的脚本, 而不是走完全可视编程的路线, 或许会比现在做的更好一些.
Nodebox即使在圈内也很少让人了解, 只能在Mac平台上运行或许的确会让人有距离感. 好消息是, Nodebox2正在努力支持Windows, 并且有可能非官方的支持Linux
非常有意思的是, Nodebox第一版本里使用的是OSX的python, 并且基于Cocoa的平台提供多媒体能力.
在第二版中, 似乎放弃了使用CPython的意图, 转而使用Jython.
猜测或许是因为Java平台提供了统一的多媒体接口, 而且Jython2.5也不再是beta状态了.
当然也许作者原本就擅长Java所以是Jython的用户. 当然这仅仅是我的猜测.
毕竟从作者的角度, 把opengl用python包装一遍并不是什么愉快的工作, java平台自己可能做的不错. 至少这里我们看到了又一个jython的经典案例.
在processing之外, 我们看到了一个支持动态数据类型的脚本的工具, 的确值得欣喜.
和使用openframework的朋友聊天, 看来在商业应用上, 似乎processing还是没有表现出足够的性能. 所以Nodebox和processing也仅仅作为prototype的工具, 还是相当不错的选择.
当然还有一些朋友讲了另外一个故事: 用C++写了一个不错的游戏, 分享给论坛的用户, 结果却是无人问津. EXE文件在当今这个时代确实是一个尴尬的东西, 除非你的产品很有名气, 否则用户不会轻易执行你的作品. jar在这方面倒是很有优势.
如果Nodebox将来可以编译成java applet, 也将是一件很有意思的事情.
最后从现在的beta本版的角度来看, Nodebox会加入一些可视编程的元素, 这也能体现Node的特性. 用户不再需要为问题写出通篇的程序, 而是通过串联一些特定的程序模块来解决问题. 这为程序员和艺术家之间的合作提供了不错的方案. 像Puredata/MaxMSP之类的工具, 如果可以更加融合一些通用的脚本, 而不是走完全可视编程的路线, 或许会比现在做的更好一些.

feed