Stretch Goal Kickstarter - Multimedia

[capellan]

If LiveCode developers had to choose between:

1) implementing Box2d into LiveCode*
(to create games and simulations) OR...
2) implementing a Python interpreter into Livecode**
(to run Python and all it's libraries)

What would choose LiveCode developers?

* Box2D is developed on Windows using Visual C++.
Ports are also available for Flash, Java, C#, Python.

** https://docs.python.org/2/extending/embedding.html

[shaosean]

I don't think the original issue was with having to choose between them.. It was the fact that RunRev stated they would add the 3D engine if a certain dollar amount was raised, and apparently it was.. Then they quietly killed it off of their roadmap.. Replace the 3D feature with any feature that you want and you would probably feel the same way, and doubly so for people who donated money..

[richmond62]

It was the fact that RunRev stated they would add the 3D engine if a certain dollar amount was raised, and apparently it was..

True: but you always get the sort of response you got from Richard Gaskin, so there is little point in taking issue with him;
his eyes are "smeared over with the love of Godhead" (to use a phrase used elsewhere)
and never seems very keen to admit that Livecode, for all their talk of a 'Community'
only believe in a community that is not a reciprocal arrangement.

I have pointed out the above many, many times, and been slammed and slagged off for doing
so many, many times; because it is an inconvenient truth which Livecode really do need to address
but haven't, and show no signs of intending to.

So: what is to be done?

Well; if you are not like me

[someone who has spent the better part of 15 years investing 80% of his spare time in learning
how to get Livecode to do the things he wants = putting my eggs in one basket?]:

1. You can decamp and use another programming suite.

2. You can go on using Livecode and keep quiet.

3. Go on making yourself unpopular, like me, by pointing out these things.

Ultimately, if one looks at things in a reasonably balanced fashion, Livecode are more "touchy-feely" with
their loyal users than most other providers of programming suites, and they produce the open-source version,
(which, considering they are not being bank-rolled by some socking great engineering firm or something
is pretty amazing), so I'm just going to stick with my self-appointed role (i.e. #3), as:

4. I'm a big boy and can cope with the "flak".

5. I do, paradoxically, think that Livecode knocks the socks off most other programming suites,
and as an educational tool for entry-level programming it really rocks.

6. I contributed a sum to the Kickstarter, so I feel I have a right to go on "kicking".

[shaosean]

While I didn't contribute to the fundraising, nor do I really code in LiveCode any more (just recently starting to poke my nose back in everybody's business ) I do think just dropping features that people prepaid for, especially with no updates about it, is a little sucky.. Maybe there were people who only contributed because of a certain feature and they were basically told they would get it if a certain dollar amount was met and then RunRev Ltd decides to pull it for no reason..

From what was mentioned earlier in this thread, a new multimedia layer was part of the KickStarter, but apparently the Linux version is dependent on further funding of the Infinite LiveCode.. This seems sucky to me too..

Personally I won't pay for promised features, I will pay for delivered features.. And in all honesty, LiveCode is way out of my price range for just fiddling around (yes, there's the Community version, but I don't like the licensing that gets forced on my code)

[FourthWorld]

True: but you always get the sort of response you got from Richard Gaskin, so there is little point in taking issue with him;
his eyes are "smeared over with the love of Godhead" (to use a phrase used elsewhere)
and never seems very keen to admit that Livecode, for all their talk of a 'Community'
only believe in a community that is not a reciprocal arrangement.

I have pointed out the above many, many times, and been slammed and slagged off for doing
so many, many times;

Do you not see the irony in your words?

You just made a directly personal dismissal of me, and then complain that you're the victim of that very sort of dismissal.

Going forward let's please try to keep this professional, focused on actionable outcomes.

I agree with you and shaosean that it would be ideal if everything the core team wanted to do was affordable.

We're all grateful that the LiveCode Kickstarter campaign didn't wind up like the nearly one-in-ten other funded projects there that never deliver anything at all, but it's true that there are a few remaining items still outstanding on this one.

Thus far they've delivered most of what was funded, with some of the few remaining items like the Linux multimedia player dependent on the Foreign Function Interace in development now. Like most projects of this scope (~80%, according to ACM literature), unanticipatable cost overruns have required them to shuffle priorities. And as new users come on board the needs of the audience as a whole also shift over time.

So things like box2d do indeed appear to have taken a back seat, while more critical features never funded through Kickstarter have been delivered, like Android intents, enhanced clipboard support, and more.

I've earnestly tried my best to help answer your question about the campaign in general, and box2d specifically.

There have been posts from Kevin about the Kickstarter campaign here and on the use-livecode list where you're subscribed, and the most complete listing of additions delivered from that project is in the post I linked to from the company blog.

Did you read it?

As for box2d, I've suggested that since that one wasn't specifically addressed there you might write to the company to inquire about its status going forward.

Did you write to them about that?

As for your opinions about community engagement, you noted:

they produce the open-source version, (which, considering they are not being bank-rolled by some socking great engineering firm or something is pretty amazing)

Very amazing when we consider that more than 75% of the LiveCode audience is using the free and open Community Edition.

While the scope of community contributions has been growing, most of the effort to keep that going is paid for by the core team via licensing and other revenue. The Kickstarter campaign was several years ago; those funds have long been spent on the 90+% of those goals already delivered. Ongoing, licensees pay for most of the development costs of the software enjoyed by non-licensees.

What would you like to see from the community and the core team that would seem more "reciprocal" to you?

[jacque]

Infinite LiveCode is in progress, as I understand it, and does not require additional fundraising.

There's a lot of assumptions happening here but I haven't seen anyone actually ask the team for information, which is all Richard suggested.

Human nature impels us to believe what we hear without any fact checking, and to react viscerally to speculation as though it were fact. This is such common behavior that it is now the way the US elects its political figures. It may well be that a feature was dropped from the road map, but it may also be that it was inadvertently omitted during the site rewrite. It's only fair to ask for an explanation before jumping to conclusions.

[richmond62]

You just made a directly personal dismissal of me, and then complain that you're the victim of that very sort of dismissal.

Ha, Ha: good point

....right by the small and curlies . . .

I do apologise.

[okk]

Hi, this is an old thread, but I think in the heat of the discussion my point (I was the OP) was a bit lost. I just would like alwaysbuffer to work again. When in the stretch goal improved media support was promised I at least thought that stuff that worked earlier on would work again in LC 8. Two of the projects I invested a lot of energy into require alwaysbuffer to work, so in the moment I develop on an old Macbookpro with MacOS 10.8 and LC 6.5.2. I guess it has to do with the switch from Quicktime to AVFoundation framework. The Playerobject seems to use a non-native controller which in my tests was problematic at best. See my original post for links.

For what I understand the controller for the player object is not native. It's some "home made" one, and I had some serious performance issues with it. I tried to show it in this video: https://vimeo.com/147381340, the related forum discussion is here: http://forums.livecode.com/viewtopic.php?f=10&t=25989 - look the last few posts. I also cannot see that the alwaysbuffer issue has been addressed, see here: http://quality.livecode.com/show_bug.cgi?id=12811 ...

That's all I wish to get clarified. Will it be impossible to draw on a Playerobject with reasonable playback performance? I don't think that it is too much asked in light of the multimedia stretch goal. Thanks for insights.

Oliver

[jacque]

According to the dictionary, alwaysBuffer works everywhere except on Windows, since apparently DirectShow doesn't support it.

[okk]

Hi, unfortunately the dictionary isn't always right. See the bug submitted here: http://quality.livecode.com/show_bug.cgi?id=12811 It was submitted and confirmed in 2014 but it hasn't been addressed. That's why in my opinion the stretch goal hasn't been met, I don't even dare to ask to get back some functionality we had with the QTExtended external. Best. Oliver

[FourthWorld]

I don't even dare to ask to get back some functionality we had with the QTExtended external.

The QTExtended external was never part of the LiveCode language. And to the degree that it was dependent on QuickTime, it may not be possible for it to be updated because Apple has dropped support for QuickTime.

[okk]

Hi Richard, I know that QTExtended was from an external developer, but it greatly expanded multimedia support for Livecode. But lets not talk about QTExtended. I just would like that somebody agrees with me that alwaysBuffer should work again in order to talk about the stretch goal of "Reworked Multimedia Support" to be accomplished. Two of my biggest coding projects are depending on alwaysBuffer to work properly, so I am a bit in desperation here. I am already considering switching to https://processing.org/ but I simply cannot break up with LC (yet).

I also don't believe the current player controller is native as it was stated in the stretch goal. I had some strange performance issues with it, I tried to show it here: https://vimeo.com/147381340 My suspicion is that it redraws the controller-bar far more often than necessary, thus slowing down other frequent redraws of the screen (sorry if this is not the correct lingo and I am more or less guessing here).

I also want to make clear that I don't want my post to be taken as a dismissal of any of the great work done with livecode on other fronts.

Best
Oliver

[FourthWorld]

I just would like that somebody agrees with me that alwaysBuffer should work again in order to talk about the stretch goal of "Reworked Multimedia Support" to be accomplished. Two of my biggest coding projects are depending on alwaysBuffer to work properly, so I am a bit in desperation here. I am already considering switching to https://processing.org/ but I simply cannot break up with LC (yet).

I also don't believe the current player controller is native as it was stated in the stretch goal. I had some strange performance issues with it, I tried to show it here: https://vimeo.com/147381340 My suspicion is that it redraws the controller-bar far more often than necessary, thus slowing down other frequent redraws of the screen (sorry if this is not the correct lingo and I am more or less guessing here).

The alwaysBuffer property has always impacted performance, which is to be expected given the additional load it introduces within LiveCode:

When alwaysBuffer is false, the media engine (formerly QT, not whatever's native to the host OS) takes control of the player's rectangle and paints directly into it.

When alwaysBuffer is true, the media engine paints into an offscreen buffer managed by LC, which LC can then use to handle the layer compositing needed to accommodate rendering other objects on top of it. Since this needs to happen dozens of times a second, it will tax CPU more than the default non-buffered method, and will impair performance.

So the question is: are you able to see a noticeable performance degradation with alwaysBuffer when comparing with older versions?

If so please file a bug report with a sample stack or recipe illustrating the problem, and hopefully the team can find a way to restore some of that lost performance. Perhaps they can revise the tiling subsystem to more frequently redraw only the video rect without redrawing other elements. Then again, that may obviate the whole point of having alwayBuffer, since of course it's only needed when you want to have LC controls rendered on top of a video, and those controls may extend beyond the video object's bounds.

[bn]

Oliver,

I feel your pain. When I was looking around for a programing environment the topmost requirement was something like alwaysBuffer. And Revolution as it was called at that time had it and so I was sold.
This was in a scientific context where overlaying a player with objects was a necessity for a specific type of analysis. Is still working like a charm but in an old version of Revolution.

Without alwaysBuffer I would not be on this forum.

What I think is that the player in its current form is only a temporary solution because once the LivecodeBuilder foreign function interface is done a more native player could probably be done without doing it from scratch.
Hopefully then alwaysBuffer will be reinstated.

Kind regards
Bernd

[FourthWorld]

Bernd, is alwaysBuffer completely absent or merely slower?

Do you have the bug report number for this?