You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(97) |
Dec
(24) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(44) |
Feb
(44) |
Mar
(75) |
Apr
(101) |
May
(38) |
Jun
(21) |
Jul
(25) |
Aug
(14) |
Sep
(30) |
Oct
(16) |
Nov
(27) |
Dec
(60) |
2004 |
Jan
(10) |
Feb
(16) |
Mar
(15) |
Apr
|
May
|
Jun
(5) |
Jul
(43) |
Aug
(74) |
Sep
(76) |
Oct
(80) |
Nov
(24) |
Dec
(12) |
2005 |
Jan
(75) |
Feb
(39) |
Mar
(8) |
Apr
(2) |
May
(11) |
Jun
(6) |
Jul
(23) |
Aug
(20) |
Sep
(25) |
Oct
(9) |
Nov
(7) |
Dec
(27) |
2006 |
Jan
(24) |
Feb
(53) |
Mar
(5) |
Apr
(60) |
May
(36) |
Jun
(38) |
Jul
(13) |
Aug
(6) |
Sep
(17) |
Oct
(47) |
Nov
(2) |
Dec
(8) |
2007 |
Jan
(15) |
Feb
(43) |
Mar
(55) |
Apr
(22) |
May
(18) |
Jun
(22) |
Jul
(32) |
Aug
(6) |
Sep
(21) |
Oct
(9) |
Nov
(20) |
Dec
|
2008 |
Jan
(12) |
Feb
(39) |
Mar
(8) |
Apr
(11) |
May
(20) |
Jun
(1) |
Jul
(5) |
Aug
(6) |
Sep
(2) |
Oct
(1) |
Nov
(46) |
Dec
(2) |
2009 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
|
May
(10) |
Jun
(9) |
Jul
(1) |
Aug
(4) |
Sep
(8) |
Oct
(21) |
Nov
(2) |
Dec
|
2010 |
Jan
(5) |
Feb
(33) |
Mar
(8) |
Apr
(7) |
May
(3) |
Jun
(10) |
Jul
(27) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2011 |
Jan
(8) |
Feb
|
Mar
(2) |
Apr
|
May
(26) |
Jun
(1) |
Jul
|
Aug
(17) |
Sep
|
Oct
|
Nov
|
Dec
(12) |
2012 |
Jan
(8) |
Feb
|
Mar
|
Apr
(29) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(7) |
Dec
|
2013 |
Jan
|
Feb
(2) |
Mar
|
Apr
(18) |
May
(2) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(7) |
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(9) |
Dec
(15) |
2015 |
Jan
(15) |
Feb
(9) |
Mar
(1) |
Apr
(9) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2016 |
Jan
|
Feb
(13) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Eric N. <er...@co...> - 2016-03-03 18:14:42
|
Hi guys, sorry not to get back sooner about this. Russell, thanks for your offer. I will contact you separately about the SourceForge account. Chris, did you have a new version of the plugin to test? If you e-mail me I'll set you up with a 64-bit version of Magic you can experiment with. Best, Eric On Tue, Feb 23, 2016 at 8:00 AM, Russell <bob...@br...> wrote: > Hi Eric, > > I'd say 1.6 is pretty official. The feature set is well established, a lot > of work has gone into it and it would be great if you were able to help > with getting the spec. finished. > > As regards 1.7 we'd probably want to come to a consensus on this list > before looking at setting up a new version project. > > Please correct me if I'm wrong but I think the last movement on the 1.6 > spec. was this commit by Tom (bangnoise): > https://sourceforge.net/p/freeframe/svn/135/ - 'Reword pointer-sized > storage requirements, add requirement that members be naturally aligned - > spec needs further modification to either list sizes of structs on known > platforms or not list sizes at all' > > Unless anyone objects I can sign you up as a developer on freeframe > sourceforge so that you get SVN permissions to update the 1.6 spec. I just > need a sourceforge ID for you to do that. > > Russell > > > > > On 22/02/2016 18:24, Eric Newman wrote: > > > If anyone is inspired to complete the 1.6 spec then go for it - it's way >> overdue. >> > > I would be happy to take a look at it, but exactly who else would need to > be involved to make it an "official" release? > > Also, what is the "official" process for adding new features to the spec? > > If I could add all the features I wanted to a new Freeframe version > (1.7?), I would use it exclusively as Magic's plugin format, and abandon > Magic's native SDK. If other apps got on board, we'd have a whole new wave > of plugin development and sharing. > > E > > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > Freeframe-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeframe-develop > > |
From: Russell <bob...@br...> - 2016-02-23 16:24:19
|
Hi Eric, I'd say 1.6 is pretty official. The feature set is well established, a lot of work has gone into it and it would be great if you were able to help with getting the spec. finished. As regards 1.7 we'd probably want to come to a consensus on this list before looking at setting up a new version project. Please correct me if I'm wrong but I think the last movement on the 1.6 spec. was this commit by Tom (bangnoise): https://sourceforge.net/p/freeframe/svn/135/ - 'Reword pointer-sized storage requirements, add requirement that members be naturally aligned - spec needs further modification to either list sizes of structs on known platforms or not list sizes at all' Unless anyone objects I can sign you up as a developer on freeframe sourceforge so that you get SVN permissions to update the 1.6 spec. I just need a sourceforge ID for you to do that. Russell On 22/02/2016 18:24, Eric Newman wrote: > > If anyone is inspired to complete the 1.6 spec then go for it - > it's way overdue. > > > I would be happy to take a look at it, but exactly who else would need > to be involved to make it an "official" release? > > Also, what is the "official" process for adding new features to the spec? > > If I could add all the features I wanted to a new Freeframe version > (1.7?), I would use it exclusively as Magic's plugin format, and > abandon Magic's native SDK. If other apps got on board, we'd have a > whole new wave of plugin development and sharing. > > E |
From: ck <ck...@gm...> - 2016-02-23 03:31:52
|
I was mistaken about the 64-bit issue still being present in 1.6. I was looking in the wrong place in the SVN. Sorry about that! Looks like the casting is gone altogether. -Chris |
From: ck <ck...@gm...> - 2016-02-22 23:24:59
|
I did find an issue that would likely cause a crash, which I unthinkingly inherited from the FFGL SDK example plugins. The examples contain code similar to the following: in GetParameter: *((float *)(unsigned)&dwRet) = m_Brightness; in SetParameter: m_Brightness = *((float *)(unsigned)&(pParam->NewParameterValue)); The use of unsigned in these expressions would very likely crash a 64-bit Windows app, by truncating a 64-bit pointer to its least significant 32 bits. Unlike Linux, Microsoft chose not to increase the size of int and unsigned to 64-bit. I expect replacing unsigned with UINT_PTR would solve the problem, because UINT_PTR is either 32-bit or 64-bit depending on the platform. However freeframe.h does not define UINT_PTR for non-Windows platforms, unlike DWORD and BYTE. I should point out that this is issue is still present in the 1.6 sources, the only difference being that the following comment appears: //sizeof(DWORD) must == sizeof(float) But the comment misses the point: casting a pointer to unsigned is a fatal bug in x64 Windows, regardless of DWORD and float both being 32 bits. My suggestion would be to conditionally define the two most useful 32/64 bit mutable types (INT_PTR and UINT_PTR) much as Windows does, but using the 64-bit types that are now part of the C++ standard, instead of Microsoft-specific types such as __int64. #ifndef _WIN32 #if defined(_WIN64) typedef int64_t INT_PTR, *PINT_PTR; typedef uint64_t UINT_PTR, *PUINT_PTR; #else typedef int32_t INT_PTR, *PINT_PTR; typedef uint32_t UINT_PTR, *PUINT_PTR; #endif #endif With the above mutable types defined, the get/set parameter code should be: *((float *)(UINT_PTR)&dwRet) = m_Brightness; m_Brightness = *((float *)(UINT_PTR)&(pParam->NewParameterValue)); Eric: Would you be willing to try this fix and see if it solves the crash in Magic? I can build the plugin for you if that makes things easier. Best regards, Chris |
From: Eric N. <er...@co...> - 2016-02-22 18:25:06
|
> > I am not sure of whether to make 64bit plugins at the moment if only Magic > supports them. What do you think about 64bit? Probably not worth it, especially since Magic has built-in Spout. Magic also has its own plugin SDK which is a superset of Freeframe, so it would be silly to use Freeframe to develop a Magic-only plugin. If anyone is inspired to complete the 1.6 spec then go for it - it's way > overdue. > I would be happy to take a look at it, but exactly who else would need to be involved to make it an "official" release? Also, what is the "official" process for adding new features to the spec? If I could add all the features I wanted to a new Freeframe version (1.7?), I would use it exclusively as Magic's plugin format, and abandon Magic's native SDK. If other apps got on board, we'd have a whole new wave of plugin development and sharing. E On Sun, Feb 21, 2016 at 6:14 PM, ck <ck...@gm...> wrote: > I'm sorry to hear the 64-bit version doesn't work properly. But it > sounds like I should hold off on rebuilding it with 1.6 until the spec > is published. > > I do have a Mac OSX version available now; thanks to Michael Dewberry > for building it. It's here: > https://sourceforge.net/projects/triplight/files/1.0.00.015/ > > Or you can get it at GitHub if you prefer. > > Would it be useful to add it to the plugin database at freeframe.org? > It looks like only one plugin was added since 2011. Is there a more > current list somewhere else? > > Chris > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > Freeframe-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeframe-develop > |
From: ck <ck...@gm...> - 2016-02-22 02:14:43
|
I'm sorry to hear the 64-bit version doesn't work properly. But it sounds like I should hold off on rebuilding it with 1.6 until the spec is published. I do have a Mac OSX version available now; thanks to Michael Dewberry for building it. It's here: https://sourceforge.net/projects/triplight/files/1.0.00.015/ Or you can get it at GitHub if you prefer. Would it be useful to add it to the plugin database at freeframe.org? It looks like only one plugin was added since 2011. Is there a more current list somewhere else? Chris |
From: Tom B. <ban...@gm...> - 2016-02-21 20:29:34
|
Just a word on where 64-bit is - the 1.6 spec is not complete as it doesn't describe that structure members are to be naturally aligned for their target platform. Your compiler is almost certainly doing this already, but the spec and headers need to make this explicit. If anyone is inspired to complete the 1.6 spec then go for it - it's way overdue. On 21 February 2016 at 04:15, Lynn Jarvis <lea...@in...> wrote: > Sorry Eric, I was too hasty with the reply. > > I meant that Chris would probably need to convert the plugin itself from > 1.5 to 1.6. As far as I can see the source is using 1.5. > > Being lazy I used the same code as in FFGL 1.5 for the FBO extensions. > Somebody recently discovered that the cast to (unsigned) was a 32bit type > and so did not resolve to a 64 bit pointer. You will find that this cast > has been removed for FFGL 1.6. You are right with the other 32bit types I > think. > > I have tried the 1.6 examples as 64bit in Magic and they all work fine. > When I came to try my own code I came across a strange bug with strings. > > "SetTextParameter" crashed when accessing "const char *value". This turned > out to be a "bad pointer". But it can be detected. > > > FFResult SpoutSender64::SetTextParameter(unsigned int index, const char > *value) > { > UINT_PTR ucb = 1; > switch (index) { > case FFPARAM_SharingName: > > // Bad read pointer when the text entry field is empty > > // IsBadReadPtr(), IsBadWritePtr(), IsBadCodePtr(), > IsBadStringPtr() for Windows > if(!IsBadReadPtr((const void *)value, ucb)) { > > strcpy_s(UserSenderName, 256, value); > } > break; > etc.. > > > I am not sure of whether to make 64bit plugins at the moment if only Magic > supports them. What do you think about 64bit? > > > > ----- Original Message ----- > From: > "FreeFrame In-depth technical discussion" < > fre...@li...> > > To: > "Lynn Jarvis" <lea...@in...>, "FreeFrame In-depth technical > discussion" <fre...@li...> > Cc: > > Sent: > Sat, 20 Feb 2016 18:21:44 -0800 > Subject: > Re: [Freeframe-develop] TripLight: x64 version > > > Yup I'm already using v1.6. > > The crash happens when I retrieve the PluginExtendedInfoStruct via > FF_GETEXTENDEDINFO. The pointer that is returned is invalid. So it might > be something inside the plugin that isn't handled correctly. > > But I can avoid the crash if I simply don't ask for the extended info. > However, the plugin still doesn't display anything -- I just get a blank > screen. > > With the same exact code, the 32-bit version of the plugin runs fine. > > A lot of the structs in FreeFrame.h seem to be forcing 32-bit types > (FFUInt32), which might introduce a portability issue to 64-bit. Also, the > FFMixed typedef is a union between an FFUInt32 and a void*, the latter of > which would be 64-bit in a 64-bit build configuration. Could be problematic > > On Sat, Feb 20, 2016 at 5:30 AM, Lynn Jarvis <lea...@in...> > wrote: > >> I think you would need to convert to FFGL 1.6 first. >> >> >> >> ----- Original Message ----- >> From: >> "FreeFrame In-depth technical discussion" < >> fre...@li...> >> >> To: >> "FreeFrame In-depth technical discussion" < >> fre...@li...> >> Cc: >> >> Sent: >> Fri, 19 Feb 2016 14:50:02 -0800 >> Subject: >> Re: [Freeframe-develop] TripLight: x64 version >> >> >> Hmm, the 64-bit plugin doesn't seem to work. It crashes my app in fact. >> But, it might be something I'm doing wrong. I'll have a closer look and >> see if I can figure it out. >> >> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >> _______________________________________________ >> Freeframe-develop mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeframe-develop >> >> > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > Freeframe-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeframe-develop > > |
From: Lynn J. <lea...@in...> - 2016-02-21 04:15:41
|
Sorry Eric, I was too hasty with the reply. I meant that Chris would probably need to convert the plugin itself from 1.5 to 1.6. As far as I can see the source is using 1.5. Being lazy I used the same code as in FFGL 1.5 for the FBO extensions. Somebody recently discovered that the cast to (unsigned) was a 32bit type and so did not resolve to a 64 bit pointer. You will find that this cast has been removed for FFGL 1.6. You are right with the other 32bit types I think. I have tried the 1.6 examples as 64bit in Magic and they all work fine. When I came to try my own code I came across a strange bug with strings. "SetTextParameter" crashed when accessing "const char *value". This turned out to be a "bad pointer". But it can be detected. FFResult SpoutSender64::SetTextParameter(unsigned int index, const char *value) { UINT_PTR ucb = 1; switch (index) { case FFPARAM_SharingName: // Bad read pointer when the text entry field is empty // IsBadReadPtr(), IsBadWritePtr(), IsBadCodePtr(), IsBadStringPtr() for Windows if(!IsBadReadPtr((const void *)value, ucb)) { strcpy_s(UserSenderName, 256, value); } break; etc.. I am not sure of whether to make 64bit plugins at the moment if only Magic supports them. What do you think about 64bit? ----- Original Message ----- From: "FreeFrame In-depth technical discussion" To:"Lynn Jarvis" , "FreeFrame In-depth technical discussion" Cc: Sent:Sat, 20 Feb 2016 18:21:44 -0800 Subject:Re: [Freeframe-develop] TripLight: x64 version Yup I'm already using v1.6. The crash happens when I retrieve the PluginExtendedInfoStruct via FF_GETEXTENDEDINFO. The pointer that is returned is invalid. So it might be something inside the plugin that isn't handled correctly. But I can avoid the crash if I simply don't ask for the extended info. However, the plugin still doesn't display anything -- I just get a blank screen. With the same exact code, the 32-bit version of the plugin runs fine. A lot of the structs in FreeFrame.h seem to be forcing 32-bit types (FFUInt32), which might introduce a portability issue to 64-bit. Also, the FFMixed typedef is a union between an FFUInt32 and a void*, the latter of which would be 64-bit in a 64-bit build configuration. Could be problematic. On Sat, Feb 20, 2016 at 5:30 AM, Lynn Jarvis wrote: I think you would need to convert to FFGL 1.6 first. ----- Original Message ----- From: "FreeFrame In-depth technical discussion" To:"FreeFrame In-depth technical discussion" Cc: Sent:Fri, 19 Feb 2016 14:50:02 -0800 Subject:Re: [Freeframe-develop] TripLight: x64 version Hmm, the 64-bit plugin doesn't seem to work. It crashes my app in fact. But, it might be something I'm doing wrong. I'll have a closer look and see if I can figure it out. ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 [4] _______________________________________________ Freeframe-develop mailing list Fre...@li... [5] https://lists.sourceforge.net/lists/listinfo/freeframe-develop [6] Links: ------ [1] mailto:lea...@in... [2] mailto:fre...@li... [3] mailto:fre...@li... [4] http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 [5] mailto:Fre...@li... [6] https://lists.sourceforge.net/lists/listinfo/freeframe-develop |
From: Eric N. <er...@co...> - 2016-02-21 02:51:09
|
Yup I'm already using v1.6. The crash happens when I retrieve the PluginExtendedInfoStruct via FF_GETEXTENDEDINFO. The pointer that is returned is invalid. So it might be something inside the plugin that isn't handled correctly. But I can avoid the crash if I simply don't ask for the extended info. However, the plugin still doesn't display anything -- I just get a blank screen. With the same exact code, the 32-bit version of the plugin runs fine. A lot of the structs in FreeFrame.h seem to be forcing 32-bit types (FFUInt32), which might introduce a portability issue to 64-bit. Also, the FFMixed typedef is a union between an FFUInt32 and a void*, the latter of which would be 64-bit in a 64-bit build configuration. Could be problematic. On Sat, Feb 20, 2016 at 5:30 AM, Lynn Jarvis <lea...@in...> wrote: > I think you would need to convert to FFGL 1.6 first. > > > > ----- Original Message ----- > From: > "FreeFrame In-depth technical discussion" < > fre...@li...> > > To: > "FreeFrame In-depth technical discussion" < > fre...@li...> > Cc: > > Sent: > Fri, 19 Feb 2016 14:50:02 -0800 > Subject: > Re: [Freeframe-develop] TripLight: x64 version > > > Hmm, the 64-bit plugin doesn't seem to work. It crashes my app in fact. > But, it might be something I'm doing wrong. I'll have a closer look and > see if I can figure it out. > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > Freeframe-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeframe-develop > > |
From: Lynn J. <lea...@in...> - 2016-02-20 13:30:57
|
I think you would need to convert to FFGL 1.6 first. ----- Original Message ----- From: "FreeFrame In-depth technical discussion" To:"FreeFrame In-depth technical discussion" Cc: Sent:Fri, 19 Feb 2016 14:50:02 -0800 Subject:Re: [Freeframe-develop] TripLight: x64 version Hmm, the 64-bit plugin doesn't seem to work. It crashes my app in fact. But, it might be something I'm doing wrong. I'll have a closer look and see if I can figure it out. |
From: Eric N. <er...@co...> - 2016-02-19 22:50:17
|
Hmm, the 64-bit plugin doesn't seem to work. It crashes my app in fact. But, it might be something I'm doing wrong. I'll have a closer look and see if I can figure it out. On Tue, Feb 16, 2016 at 3:59 PM, ck <ck...@gm...> wrote: > Thank you for the feedback! I built a 64-bit version of the plugin for > you to try, which you can download here: > https://sourceforge.net/projects/triplight/files/1.0.00.015/ > The filename is: TripLight-1.0.00.015-freeframe-x64.zip > > Re the frame rate, I hadn't considered that anyone would run at 2,500 > FPS. However the plugin has a relevant feature you might not have > noticed: it provides *two* parameters for color cycling rate, Speed > and Scale. Scale sets the upper limit of Speed. The intention was to > allow very slow color cycling rates to be controlled more precisely, > but it also means the plugin can accommodate a wide range of frame > rates without sacrificing granularity. > > Of more concern would be drastic variation in frame rate during a > given instance of the plugin, though I'm unclear on why this would be > an expected case. But I will look into the feasibility of correcting > the color deltas for the frame rate. > > I always wondered why the target frame rate wasn't passed to the > plugin. I guess it doesn't really matter since the plugin can measure > it for itself. > > chris > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > Freeframe-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeframe-develop > |
From: ck <ck...@gm...> - 2016-02-17 00:00:04
|
Thank you for the feedback! I built a 64-bit version of the plugin for you to try, which you can download here: https://sourceforge.net/projects/triplight/files/1.0.00.015/ The filename is: TripLight-1.0.00.015-freeframe-x64.zip Re the frame rate, I hadn't considered that anyone would run at 2,500 FPS. However the plugin has a relevant feature you might not have noticed: it provides *two* parameters for color cycling rate, Speed and Scale. Scale sets the upper limit of Speed. The intention was to allow very slow color cycling rates to be controlled more precisely, but it also means the plugin can accommodate a wide range of frame rates without sacrificing granularity. Of more concern would be drastic variation in frame rate during a given instance of the plugin, though I'm unclear on why this would be an expected case. But I will look into the feasibility of correcting the color deltas for the frame rate. I always wondered why the target frame rate wasn't passed to the plugin. I guess it doesn't really matter since the plugin can measure it for itself. chris |
From: Eric N. <er...@co...> - 2016-02-16 18:48:16
|
Hey Chris, just FYI, your message went to my Spam folder because of the ad at the bottom, so it may have been filtered out for others as well. Luckily I don't get a lot of Spam at this address so I noticed it. I tested your plugin in my application, Magic (https://magicmusicvisuals.com), and it seems to work well. The only thing I'd suggest is to not assume a steady 60 fps. When I'm developing a plugin I always use the time difference between the current frame and the previous frame, so that everything will look the same regardless of the fps. These days there are many gaming monitors that run at 120 or 144 fps, and my application (and others) allow you to export movies at 24 fps, 30 fps, etc. Also, sometimes I turn off VSync for testing purposes, and when I did, your plugin ran way too fast (at ~2500 fps) and I had to set the Speed at .001. Magic is available in 64-bit and 32-bit versions, so I'd be very interested to test a 64-bit version of your plugin. You can e-mail me separately if you want. When I first added FFGL support, I noticed there was a branch in the repository for version 1.6, which appears never to have been officially released, but does seem to support 64-bit. I used this version for Magic. I've never come across a 64-bit plugin though. Maybe yours could be the first :). It would be great to start a new tradition of including 64-bit versions with FFGL plugins. Eric On Mon, Feb 15, 2016 at 11:31 AM, Chris Korda <vic...@ya...> wrote: > You may remember me as the developer of FFRend and some V1 plugins back in > the day. Well I finally got around to developing a GL plugin, an homage to > 1970s color organs called TripLight. There’s only a Windows version at the > moment, but an OSX version is in the works. I tested it via the FFGL plugin > tester, but I don’t currently have any other means of testing it. I hewed > close to the examples in the SDK, so hopefully it works fine, but if you’re > inspired to give it a go in your favorite VJ software I would greatly > appreciate hearing the result. > https://sourceforge.net/projects/triplight/files/1.0.00.015/ > > Also I have a question: I don’t see any mention of 64-bit in the SDK. > Building a 64-bit plugin appears to work, but is it useful? Is it customary > to distribute both 32-bit and 64-bit versions? Sorry if this is a FAQ. > > And another question: Other than this list, where are FreeFrame developers > hanging out? I searched but didn't find anything that felt right. VJForums > still exists, but most of the posts appear to be ancient. I did find > FreeFrame-related forums for individual hosts e.g. VJamm, Resolume etc. but > these seem to be more platform-specific. > > Best, > Chris Korda > http://whorld.org > > > > _______________________________________________ > Freeframe-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeframe-develop > > |
From: Chris K. <vic...@ya...> - 2016-02-15 19:35:01
|
You may remember me as the developer of FFRend and some V1plugins back in the day. Well I finally got around to developing a GL plugin, an homage to 1970s color organs calledTripLight. There’s only a Windows version at the moment, but an OSX version isin the works. I tested it via the FFGL plugin tester, but I don’t currently haveany other means of testing it. I hewed close to the examples in the SDK, so hopefullyit works fine, but if you’re inspired to give it a go in your favorite VJ software I would greatlyappreciate hearing the result. https://sourceforge.net/projects/triplight/files/1.0.00.015/ Also I have a question: I don’t see any mention of 64-bit in theSDK. Building a 64-bit plugin appears to work, but is it useful? Isit customary to distribute both 32-bit and 64-bit versions? Sorry if this is a FAQ. And another question: Other than this list, where are FreeFrame developers hanging out? I searched but didn't find anything that felt right. VJForums still exists, but most of the posts appear to be ancient. I did find FreeFrame-related forums for individual hosts e.g. VJamm, Resolume etc. but these seem to be more platform-specific. Best,Chris Korda http://whorld.org |
From: Lynn J. <lea...@ad...> - 2015-12-09 13:28:53
|
https://magicmusicvisuals.com/ Eric Newman has done an excellent job. I knew he was working on it, so there was no point in duplicating the work, stepping on his toes and handing it to the competition for nothing. If people want it they can pipe from Magic to Resolume. Both have Spout built in now. ----- Original Message ----- From: "FreeFrame In-depth technical discussion" To:"Lynn Jarvis" , "FreeFrame In-depth technical discussion" Cc: Sent:Wed, 9 Dec 2015 04:56:27 -0800 Subject:Re: [Freeframe-develop] Javascript-based FreeFrame, ISF Hi Lynn, > I had a look at ISF Freeframe but a commercial solution came out so there was no point. Commercial solution for ISF Freeframe? Where/what is that? ...Tim... ---- Message sent via Adam Internet WebMail - http://www.adam.com.au/ |
From: Tim T. <me...@ti...> - 2015-12-09 13:25:11
|
Hi Lynn, > I had a look at ISF Freeframe but a commercial solution came out so there was no point. Commercial solution for ISF Freeframe? Where/what is that? ...Tim... |
From: Lynn J. <lea...@ad...> - 2015-12-09 11:39:02
|
Hi Tim, this is a good piece of work. I had a look at ISF Freeframe but a commercial solution came out so there was no point. But the idea of adapting a plugin to user defined controls worked very well and I am working on a project that uses this concept with Processing and uses a Freeframe plugin as interface with an host. Modifications to Freeframe were minimal. http://spout.zeal.co/forums/topic/processing-for-resolume/ [1] If you are looking at doing a similar thing just email me. Cheers, Lynn ----- Original Message ----- From: "FreeFrame In-depth technical discussion" To:"FreeFrame In-depth technical discussion" Cc: Sent:Tue, 8 Dec 2015 20:02:28 -0800 Subject:[Freeframe-develop] Javascript-based FreeFrame, ISF Anyone doing any development with ISF [2] ? I just noticed this javascript library for it: https://github.com/msfeldstein/interactive-shader-format-js [3] Might be useful to anyone trying to do FreeFrame-like things in WebGL. ...Tim... ---- Message sent via Adam Internet WebMail - http://www.adam.com.au/ Links: ------ [1] http://spout.zeal.co/forums/topic/processing-for-resolume/ [2] http://interactiveshaderformat.com [3] https://github.com/msfeldstein/interactive-shader-format-js |
From: Tim T. <me...@ti...> - 2015-12-09 04:31:39
|
Anyone doing any development with ISF <http://interactiveshaderformat.com> ? I just noticed this javascript library for it: https://github.com/msfeldstein/interactive-shader-format-js Might be useful to anyone trying to do FreeFrame-like things in WebGL. ...Tim... |
From: Lynn J. <lea...@ad...> - 2015-05-29 12:28:57
|
Firstly thanks Edwin, definitely rendering to a texture/fbo within the plugin results in black even if the Resolume fbo id is restored afterwards. Also rendering to a texture involves setting the viewport so it becomes more trouble than it's worth. The thing I don't understand properly is what the Render Width and Height for a source plugin does differently to the Clip Transform dimensions. I guess that it is adjusting the texture size that the plugin renders into, or maybe it is doing something else. The other thing I forgot to mention is that some shaders are heavy going so some means of reducing the viewport size that the plugin gets is sometimes useful to increase perfomance. Simon, for a source plugin, iChannel0 won't be available. You need a texture input into the plugin for this to work, so it has to be an effect. Then the viewport and texture size that the plugin gets are defined by what is "under" the plugin. Also you don't have to do "plugin.plugMain(“INIT”, &buffer)" etc. because the plugin has predefined functions that handle all of that. Just follow the basic examples provided with the Freeframe distribution. Gradients is a good source example. Brightness is a good effect example. Get these going as a first step. Cheers, Lynn ----- Original Message ----- From: "FreeFrame In-depth technical discussion" To:"FreeFrame In-depth technical discussion" Cc: Sent:Fri, 29 May 2015 11:55:02 +0200 Subject:Re: [Freeframe-develop] Size of FrameBufferObject to render into Hey Edwin, thank you for your quick reply, too. What I think you mean is: I create my own FBO in some init method and overwrite the int* that I get from resolume and bind the new FBO. Then I will render in future rendercalls into this FBO. Since resolume will say something like: int buffer = -1; gl_genBuffers(&buffer,1) // generate new FBO plugin.plugMain(“INIT”, &buffer) in Plugin: gl_genBuffers(&buffer,1) // genereate another FBO over the old one. maybe delete the old one first plugin.plugMain(“FF_PROCESSOPENGL”, &buffer) in Plugin: bindBuffer if not alredy happened. render into buffer. drawEverything(…,buffer,…); did I get this right? Simon On 29 May 2015, at 08:53, Edwin de Koning wrote: Hi There, Lynn: Regarding the FBO, in Resolume we render to a FBO when we render an effect or source. But we pass in the id of our FBO with the ProcessOpenGLStruct. Just binding back to that FBO when you are done rendering to your own should do the trick, did you trry that? Edwin On Fri, May 29, 2015 at 3:31 AM, Lynn Jarvis wrote: Hi Simon, if you render into a fbo/texture within the plugin, Resolume will not get it and the result will be black. The size it renders into is determined by Resolume. But you have raised a good point. ShaderMaker was originally designed as a variation of ShaderLoader which is either an effect or a source depending on the shader, so it is set up as an effect so it can be both. But what this means is that it is not seen as a source in Resolume and the render width and height cannot be controlled. As an effect plugin it's render size depends on the size of whatever it is applied to. So in the case of a movie clip, the render size is that of the clip. I can't see any way around this for ShaderLoader because the type of shader can't be known in advance. But for a shader that generates the output, you will get the result you want if you compile ShaderMaker as a Source plugin by changing to FF_SOURCE instead of FF_EFFECT. Then ShaderMaker will be listed as a Source and when you activate it you will be able to adjust the render width and height. Of course this will only work if the shader generates to output rather than applies an effect to the incoming texture. Then you have to compile as an effect. Lynn ----- Original Message ----- From: "FreeFrame In-depth technical discussion" To: Cc: Sent: Thu, 28 May 2015 23:33:04 +0200 Subject: [Freeframe-develop] Size of FrameBufferObject to render into Hey Guys, I’m pretty new to FFGL and FreeFrame and willing to develop a plugin for Resolume on OS X. I already got the hint that https://github.com/leadedge/ShaderMaker [5] is what I am looking for. I manged to create a simple plugin, but got stuck at the following position: In https://github.com/leadedge/ShaderMaker/blob/master/FFGL/FFGL.cpp#L305 [6] (FFGL 1.6) the plugins function is called with different arguments from the host app - here resolume. One argument is functionCode it defines what “sub function” should be called. In case of FF_PROCESSOPENGL we get an ProcessOpenGLStruct too. (https://github.com/leadedge/ShaderMaker/blob/master/FFGL/FFGL.h#L123 [7]) It contains the handle to an FrameBufferObject. I assume that we render into it. This happens in https://github.com/leadedge/ShaderMaker/blob/master/ShaderMaker.cpp#L746 [8] The FrameBufferObject is already instantiated by the host app. If I play a video that is 1280x720 the size viewport / framebufferobject is 1280x720 too. This size is independent from the settings i choose in resolume and my monitors resolution. This is good for performance, but for better results I would love to get the framebufferobject in a resolution that matches at least my output devices resolution. Has anyone of you an Idea how I could achieve this? Do you guys think it could be possible to generate a new framebufferobject in the plugin and overwrite the generated in the host app? Best wishes Simon ------------------------------------------------------------------------------ _______________________________________________ Freeframe-develop mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeframe-develop ---- Message sent via Adam Internet WebMail - http://www.adam.com.au/ ------------------------------------------------------------------------------ _______________________________________________ Freeframe-develop mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeframe-develop ------------------------------------------------------------------------------ _______________________________________________ Freeframe-develop mailing list Fre...@li... [9] https://lists.sourceforge.net/lists/listinfo/freeframe-develop ---- Message sent via Adam Internet WebMail - http://www.adam.com.au/ Links: ------ [1] mailto:ed...@re... [2] mailto:lea...@ad... [3] mailto:fre...@li... [4] mailto:fre...@li... [5] https://github.com/leadedge/ShaderMaker [6] https://github.com/leadedge/ShaderMaker/blob/master/FFGL/FFGL.cpp#L305 [7] https://github.com/leadedge/ShaderMaker/blob/master/FFGL/FFGL.h#L123 [8] https://github.com/leadedge/ShaderMaker/blob/master/ShaderMaker.cpp#L746 [9] mailto:Fre...@li... |
From: Simon T. <dev...@th...> - 2015-05-29 09:55:14
|
Hey Edwin, thank you for your quick reply, too. What I think you mean is: I create my own FBO in some init method and overwrite the int* that I get from resolume and bind the new FBO. Then I will render in future rendercalls into this FBO. Since resolume will say something like: int buffer = -1; gl_genBuffers(&buffer,1) // generate new FBO plugin.plugMain(“INIT”, &buffer) in Plugin: gl_genBuffers(&buffer,1) // genereate another FBO over the old one. maybe delete the old one first plugin.plugMain(“FF_PROCESSOPENGL”, &buffer) in Plugin: bindBuffer if not alredy happened. render into buffer. drawEverything(…,buffer,…); did I get this right? Simon > On 29 May 2015, at 08:53, Edwin de Koning <ed...@re...> wrote: > > Hi There, > > Lynn: > Regarding the FBO, in Resolume we render to a FBO when we render an > effect or source. But we pass in the id of our FBO with the > ProcessOpenGLStruct. Just binding back to that FBO when you are done > rendering to your own should do the trick, did you trry that? > > Edwin > > On Fri, May 29, 2015 at 3:31 AM, Lynn Jarvis <lea...@ad...> wrote: >> Hi Simon, >> >> if you render into a fbo/texture within the plugin, Resolume will not get it >> and the result will be black. The size it renders into is determined by >> Resolume. >> >> But you have raised a good point. >> >> ShaderMaker was originally designed as a variation of ShaderLoader which is >> either an effect or a source depending on the shader, so it is set up as an >> effect so it can be both. >> >> But what this means is that it is not seen as a source in Resolume and the >> render width and height cannot be controlled. As an effect plugin it's >> render size depends on the size of whatever it is applied to. So in the case >> of a movie clip, the render size is that of the clip. >> >> I can't see any way around this for ShaderLoader because the type of shader >> can't be known in advance. But for a shader that generates the output, you >> will get the result you want if you compile ShaderMaker as a Source plugin >> by changing to FF_SOURCE instead of FF_EFFECT. Then ShaderMaker will be >> listed as a Source and when you activate it you will be able to adjust the >> render width and height. >> >> Of course this will only work if the shader generates to output rather than >> applies an effect to the incoming texture. Then you have to compile as an >> effect. >> >> Lynn >> >> >> >> ----- Original Message ----- >> From: >> "FreeFrame In-depth technical discussion" >> <fre...@li...> >> >> To: >> <fre...@li...> >> Cc: >> >> Sent: >> Thu, 28 May 2015 23:33:04 +0200 >> Subject: >> [Freeframe-develop] Size of FrameBufferObject to render into >> >> >> >> Hey Guys, >> >> I’m pretty new to FFGL and FreeFrame and willing to develop a plugin for >> Resolume on OS X. >> >> I already got the hint that https://github.com/leadedge/ShaderMaker is what >> I am looking for. >> I manged to create a simple plugin, but got stuck at the following position: >> In https://github.com/leadedge/ShaderMaker/blob/master/FFGL/FFGL.cpp#L305 >> (FFGL 1.6) the plugins function is called with different arguments from the >> host app - here resolume. >> One argument is functionCode it defines what “sub function” should be >> called. >> In case of FF_PROCESSOPENGL we get an ProcessOpenGLStruct too. >> (https://github.com/leadedge/ShaderMaker/blob/master/FFGL/FFGL.h#L123) >> It contains the handle to an FrameBufferObject. >> I assume that we render into it. >> This happens in >> https://github.com/leadedge/ShaderMaker/blob/master/ShaderMaker.cpp#L746 >> >> The FrameBufferObject is already instantiated by the host app. >> If I play a video that is 1280x720 the size viewport / framebufferobject is >> 1280x720 too. >> This size is independent from the settings i choose in resolume and my >> monitors resolution. >> This is good for performance, but for better results I would love to get the >> framebufferobject in a resolution that matches at least my output devices >> resolution. >> >> Has anyone of you an Idea how I could achieve this? >> >> Do you guys think it could be possible to generate a new framebufferobject >> in the plugin and overwrite the generated in the host app? >> >> Best wishes Simon >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Freeframe-develop mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeframe-develop >> >> ---- Message sent via Adam Internet WebMail - http://www.adam.com.au/ >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeframe-develop mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeframe-develop >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Freeframe-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeframe-develop |
From: Simon T. <dev...@th...> - 2015-05-29 09:49:23
|
Hello Lynn, thank you for your quick response. My shader depends on the input that comes from resolume. That means I use iChannel0 as input texture in the fragment shader and do some operations on it. I think it must be a FF_EFFECT then. And I want it to be an FF_EFFECT since I want to combine the output with some other effects. Does FF_SOURCE mean that the plugin is some kind of input video in resolume? Is it possible to read iChannel0 on FF_SOURCE? Best wishes Simon > On 29 May 2015, at 03:31, Lynn Jarvis <lea...@ad...> wrote: > > Hi Simon, > > if you render into a fbo/texture within the plugin, Resolume will not get it and the result will be black. The size it renders into is determined by Resolume. > > But you have raised a good point. > > ShaderMaker was originally designed as a variation of ShaderLoader which is either an effect or a source depending on the shader, so it is set up as an effect so it can be both. > > But what this means is that it is not seen as a source in Resolume and the render width and height cannot be controlled. As an effect plugin it's render size depends on the size of whatever it is applied to. So in the case of a movie clip, the render size is that of the clip. > > I can't see any way around this for ShaderLoader because the type of shader can't be known in advance. But for a shader that generates the output, you will get the result you want if you compile ShaderMaker as a Source plugin by changing to FF_SOURCE instead of FF_EFFECT. Then ShaderMaker will be listed as a Source and when you activate it you will be able to adjust the render width and height. > > Of course this will only work if the shader generates to output rather than applies an effect to the incoming texture. Then you have to compile as an effect. > > Lynn > > > > ----- Original Message ----- > From: > "FreeFrame In-depth technical discussion" <fre...@li...> > > To: > <fre...@li...> > Cc: > > Sent: > Thu, 28 May 2015 23:33:04 +0200 > Subject: > [Freeframe-develop] Size of FrameBufferObject to render into > > > Hey Guys, > > I’m pretty new to FFGL and FreeFrame and willing to develop a plugin for Resolume on OS X. > > I already got the hint that https://github.com/leadedge/ShaderMaker is what I am looking for. > I manged to create a simple plugin, but got stuck at the following position: > In https://github.com/leadedge/ShaderMaker/blob/master/FFGL/FFGL.cpp#L305 (FFGL 1.6) the plugins function is called with different arguments from the host app - here resolume. > One argument is functionCode it defines what “sub function” should be called. > In case of FF_PROCESSOPENGL we get an ProcessOpenGLStruct too. (https://github.com/leadedge/ShaderMaker/blob/master/FFGL/FFGL.h#L123) > It contains the handle to an FrameBufferObject. > I assume that we render into it. > This happens in https://github.com/leadedge/ShaderMaker/blob/master/ShaderMaker.cpp#L746 > > The FrameBufferObject is already instantiated by the host app. > If I play a video that is 1280x720 the size viewport / framebufferobject is 1280x720 too. > This size is independent from the settings i choose in resolume and my monitors resolution. > This is good for performance, but for better results I would love to get the framebufferobject in a resolution that matches at least my output devices resolution. > > Has anyone of you an Idea how I could achieve this? > > Do you guys think it could be possible to generate a new framebufferobject in the plugin and overwrite the generated in the host app? > > Best wishes Simon > > > ------------------------------------------------------------------------------ > _______________________________________________ > Freeframe-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeframe-develop > ---- Message sent via Adam Internet WebMail - http://www.adam.com.au/ > ------------------------------------------------------------------------------ > _______________________________________________ > Freeframe-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeframe-develop |
From: Edwin de K. <ed...@re...> - 2015-05-29 07:17:05
|
Hi There, Lynn: Regarding the FBO, in Resolume we render to a FBO when we render an effect or source. But we pass in the id of our FBO with the ProcessOpenGLStruct. Just binding back to that FBO when you are done rendering to your own should do the trick, did you trry that? Edwin On Fri, May 29, 2015 at 3:31 AM, Lynn Jarvis <lea...@ad...> wrote: > Hi Simon, > > if you render into a fbo/texture within the plugin, Resolume will not get it > and the result will be black. The size it renders into is determined by > Resolume. > > But you have raised a good point. > > ShaderMaker was originally designed as a variation of ShaderLoader which is > either an effect or a source depending on the shader, so it is set up as an > effect so it can be both. > > But what this means is that it is not seen as a source in Resolume and the > render width and height cannot be controlled. As an effect plugin it's > render size depends on the size of whatever it is applied to. So in the case > of a movie clip, the render size is that of the clip. > > I can't see any way around this for ShaderLoader because the type of shader > can't be known in advance. But for a shader that generates the output, you > will get the result you want if you compile ShaderMaker as a Source plugin > by changing to FF_SOURCE instead of FF_EFFECT. Then ShaderMaker will be > listed as a Source and when you activate it you will be able to adjust the > render width and height. > > Of course this will only work if the shader generates to output rather than > applies an effect to the incoming texture. Then you have to compile as an > effect. > > Lynn > > > > ----- Original Message ----- > From: > "FreeFrame In-depth technical discussion" > <fre...@li...> > > To: > <fre...@li...> > Cc: > > Sent: > Thu, 28 May 2015 23:33:04 +0200 > Subject: > [Freeframe-develop] Size of FrameBufferObject to render into > > > > Hey Guys, > > I’m pretty new to FFGL and FreeFrame and willing to develop a plugin for > Resolume on OS X. > > I already got the hint that https://github.com/leadedge/ShaderMaker is what > I am looking for. > I manged to create a simple plugin, but got stuck at the following position: > In https://github.com/leadedge/ShaderMaker/blob/master/FFGL/FFGL.cpp#L305 > (FFGL 1.6) the plugins function is called with different arguments from the > host app - here resolume. > One argument is functionCode it defines what “sub function” should be > called. > In case of FF_PROCESSOPENGL we get an ProcessOpenGLStruct too. > (https://github.com/leadedge/ShaderMaker/blob/master/FFGL/FFGL.h#L123) > It contains the handle to an FrameBufferObject. > I assume that we render into it. > This happens in > https://github.com/leadedge/ShaderMaker/blob/master/ShaderMaker.cpp#L746 > > The FrameBufferObject is already instantiated by the host app. > If I play a video that is 1280x720 the size viewport / framebufferobject is > 1280x720 too. > This size is independent from the settings i choose in resolume and my > monitors resolution. > This is good for performance, but for better results I would love to get the > framebufferobject in a resolution that matches at least my output devices > resolution. > > Has anyone of you an Idea how I could achieve this? > > Do you guys think it could be possible to generate a new framebufferobject > in the plugin and overwrite the generated in the host app? > > Best wishes Simon > > > ------------------------------------------------------------------------------ > _______________________________________________ > Freeframe-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeframe-develop > > ---- Message sent via Adam Internet WebMail - http://www.adam.com.au/ > > ------------------------------------------------------------------------------ > > _______________________________________________ > Freeframe-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeframe-develop > |
From: Lynn J. <lea...@ad...> - 2015-05-29 01:32:00
|
Hi Simon, if you render into a fbo/texture within the plugin, Resolume will not get it and the result will be black. The size it renders into is determined by Resolume. But you have raised a good point ShaderMaker was originally designed as a variation of ShaderLoader which is either an effect or a source depending on the shader, so it is set up as an effect so it can be both. But what this means is that it is not seen as a source in Resolume and the render width and height cannot be controlled. As an effect plugin it's render size depends on the size of whatever it is applied to. So in the case of a movie clip, the render size is that of the clip. I can't see any way around this for ShaderLoader because the type of shader can't be known in advance. But for a shader that generates the output, you will get the result you want if you compile ShaderMaker as a Source plugin by changing to FF_SOURCE instead of FF_EFFECT. Then ShaderMaker will be listed as a Source and when you activate it you will be able to adjust the render width and height. Of course this will only work if the shader generates to output rather than applies an effect to the incoming texture. Then you have to compile as an effect. Lynn ----- Original Message ----- From: "FreeFrame In-depth technical discussion" To: Cc: Sent:Thu, 28 May 2015 23:33:04 +0200 Subject:[Freeframe-develop] Size of FrameBufferObject to render into Hey Guys, I’m pretty new to FFGL and FreeFrame and willing to develop a plugin for Resolume on OS X. I already got the hint that https://github.com/leadedge/ShaderMaker is what I am looking for. I manged to create a simple plugin, but got stuck at the following position: In https://github.com/leadedge/ShaderMaker/blob/master/FFGL/FFGL.cpp#L305 (FFGL 1.6) the plugins function is called with different arguments from the host app - here resolume. One argument is functionCode it defines what “sub function” should be called. In case of FF_PROCESSOPENGL we get an ProcessOpenGLStruct too. (https://github.com/leadedge/ShaderMaker/blob/master/FFGL/FFGL.h#L123) It contains the handle to an FrameBufferObject. I assume that we render into it. This happens in https://github.com/leadedge/ShaderMaker/blob/master/ShaderMaker.cpp#L746 The FrameBufferObject is already instantiated by the host app. If I play a video that is 1280x720 the size viewport / framebufferobject is 1280x720 too. This size is independent from the settings i choose in resolume and my monitors resolution. This is good for performance, but for better results I would love to get the framebufferobject in a resolution that matches at least my output devices resolution. Has anyone of you an Idea how I could achieve this? Do you guys think it could be possible to generate a new framebufferobject in the plugin and overwrite the generated in the host app? Best wishes Simon ------------------------------------------------------------------------------ _______________________________________________ Freeframe-develop mailing list Fre...@li... https://lists.sourceforgenet/lists/listinfo/freeframe-develop ---- Message sent via Adam Internet WebMail - http://www.adam.com.au/ |
From: Simon T. <dev...@th...> - 2015-05-28 21:59:57
|
Hey Guys, I’m pretty new to FFGL and FreeFrame and willing to develop a plugin for Resolume on OS X. I already got the hint that https://github.com/leadedge/ShaderMaker is what I am looking for. I manged to create a simple plugin, but got stuck at the following position: In https://github.com/leadedge/ShaderMaker/blob/master/FFGL/FFGL.cpp#L305 (FFGL 1.6) the plugins function is called with different arguments from the host app - here resolume. One argument is functionCode it defines what “sub function” should be called. In case of FF_PROCESSOPENGL we get an ProcessOpenGLStruct too. (https://github.com/leadedge/ShaderMaker/blob/master/FFGL/FFGL.h#L123) It contains the handle to an FrameBufferObject. I assume that we render into it. This happens in https://github.com/leadedge/ShaderMaker/blob/master/ShaderMaker.cpp#L746 The FrameBufferObject is already instantiated by the host app. If I play a video that is 1280x720 the size viewport / framebufferobject is 1280x720 too. This size is independent from the settings i choose in resolume and my monitors resolution. This is good for performance, but for better results I would love to get the framebufferobject in a resolution that matches at least my output devices resolution. Has anyone of you an Idea how I could achieve this? Do you guys think it could be possible to generate a new framebufferobject in the plugin and overwrite the generated in the host app? Best wishes Simon |
From: Lynn J. <lea...@ad...> - 2015-05-28 09:38:35
|
Hi Tim, this is just fantastic... Cheers, Lynn ----- Original Message ----- From: "FreeFrame In-depth technical discussion" To:"FreeFrame In-depth technical discussion" Cc: Sent:Wed, 20 May 2015 09:03:35 -0700 Subject:[Freeframe-develop] FreeFrame-based MIDI visualizer Here's some results from my continuing exploration of realtime MIDI-driven visuals in a FreeFrame-based world: https://www.youtube.com/watch?v=ZLocbTY4g2Q [1] ...Tim... ---- Message sent via Adam Internet WebMail - http://www.adam.com.au/ Links: ------ [1] https://www.youtube.com/watch?v=ZLocbTY4g2Q |