Giter Site home page Giter Site logo

splitmedialabslimited / xjs Goto Github PK

View Code? Open in Web Editor NEW
38.0 38.0 11.0 5.72 MB

XSplit JS Framework. Make plugins for XSplit Broadcaster, quickly and easily.

License: Other

TypeScript 41.78% JavaScript 57.41% CSS 0.01% HTML 0.37% Shell 0.13% PHP 0.31%

xjs's People

Contributors

darklightblue avatar dcefram avatar dependabot[bot] avatar mikeybanez avatar miyb avatar nelson-temporal avatar ravenjohn avatar sml-meso avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

xjs's Issues

Support for browserify bundler with babelify

If you want to code using ES6, XJS framework would need you to switch your bundler from browserify to webpack since it won't work with browserify at all.

Forcing people to switch away from their preferred build process is obviously not a good thing, so we'll need to figure out a way to make XJS framework compatible with browserify (somewhat much more popular than webpack as of now) out of the box.

Automatically open extensions saved on presentation on presentation open.

When an extension is integral to a particular presentation, it would be nice if it were possible to save the current active extensions (along with their window size/position) as part of a presentation so that they open automatically when the presentation opens. In the current system, if there is an extension that is used all the time, you still have to reopen it each time you open xsplit.
~ paul-lrr

This was originally filed on issue #6

Standardize API documentation style

(mostly copy pasted from internal issue tracking: PLG-175, some parts might already be accomplished or might be outdated)

Here's the list of classes that we should tidy up:

Core/Scene Class

  • setName did not specify the parameter datatype (but has example)
  • isEmpty did not specify the return datatype (but has example)
  • searchAllForItemId does not have the standard parameter and return information
  • searchSceneWithItemId did not specify parameter datatype (but has example)
  • searchAllForItemName did not specify parameter datatype (but has example)

Core/Transition Class

  • toString did not specify the return datatype
  • toTransitionKey did not specify the return datatype

Core/AudioItem Class

  • Missing parameter/return datatype and description on most methods
  • No sample usage unlike other Item subclasses

Core/HTMLItem Class

  • No sample usage unlike other Item subclasses

System/CameraDevice Class

  • addToScene has no return datatype

System/Game Class

  • addToScene has no return datatype
  • getFpsRender, getFpsCapture, getImageName, and getReplace do not have any return datatype

System/MicrophoneDevice class

  • addToScene has no return datatype

Util Module

  • Color class and rectangle class do not have any documentation comments

View itemID in xsplit gui

Would be handy to have the ability to find/see the item ID's in the gui while developing plugins. Maybe a property or advanced tab. e.g: html, Color, layout, transition, properties/advanced.

Allow saving of authentication per XBC user instead of globally

(related to internal issue PLG-192)

Currently, plugins are able to detect authentication data through some mechanism such as local storage. When a user logs out and logs on as a different user, the plugins retain this information and will allow the second user to use the first user's credentials to that plugin's service.

Ideally, we want this to be scoped per user instead. We will need encrypted XBC user information from the application for this.

migrating from previous xui framework

I'm upgrading to this newer framework, but its not clear to me how to port what I was doing

In the previous framework, I was updating rtmp/images items with

var slot = internal.Item.attach(id, 0);
internal.Item.set('prop:item', decodeURIComponent(itemString), slot);

It's not clear what method I would use in the new framework to accomplish the same task. I'm guessing there is a way to update "_xmlparams": ?

Create version bumping task

For a quicker release process. This should update both npm and bower version numbers.

If possible, we should also automatically add the version number as a comment in the build.

stream start event

Something that wasn't available in the old plugin system, but would be extremely useful, is to have an event emitted when a channel goes online or offline. Ideally the event would include the channel object for the stream.

If I understand the new Channel class correctly, currently the only way to tell if a stream is online is to poll getActiveStreamChannels.

As a simple example use case, I would like to make a timer that shows how long a stream has been active. At the moment, I have to continually poll to see if the stream is online and then getStreamTime to see how long, but if there was an event emitted when going online and offline, I could have the timer start and stop with the stream and avoid polling all together.

Setting the Primary Microphone/Speaker seems to destroy the primary audio devices

Hey there,

When trying to set the Primary Mic/Speaker in order to increase/decrease their volume from an extension, the functions seem to destroy the primary audio devices.

I dug around a bit to cut down on the debugging, and I'm not sure if this is a problem with xjs or with xsplit's exported functions. It looks like setting "microphonedev2" just sometimes messes up.

An example of what I mean boiled down to using window.external directly, the same thing happens if you use setPrimaryMicropohone/setPrimarySpeaker: http://i.imgur.com/nnNnM8i.png

In that example I have the Default Microphone/Default Speaker selected for input/output. I do not have an Audio Preview device selected. The last device in that XML array appears to be the "XSplit Stream Audio Renderer".

As you can see, even just echoing back in the value from getting it destroys the Device array. After that happens the only way to fix it is to go manually into xsplit, change the device to something else, and save the settings. This happens for me with any combination of devices in the microphone/speaker area.

Not sure if this is an issue with the API or XSplit itself, but it makes it impossible as far as I can tell to adjust the volume of those devices. (Using Xsplit v. 2.6.1509.3002)

Improved handling of DLLs with respect to new DLL security scheme

As of latest internal XBC build, we are now able to take advantage of DLL security, but this implies several changes in development style. Current programming patterns in our plugins that require DLLs are insufficient / will result in broken or inconsistent plugins, so ideally we should encapsulate required changes in the framework so everything will be easier.

Things to note for implementation:

  • loading of DLLs should be handled. This needs asynchronous operations now so any CallDllEx calls need to wait until access is granted.
  • we now need to distinguish between CallDll and CallDllEx calls
  • enhancement: since revoking DLL grants does not fully work until the source is reloaded, the framework needs to automatically reload plugin on grant revocation. (An option to NOT reload can be specified)

@SML-MeSo @dcefram please comment on these requirements before we start implementation

Writing to the disk

Javascript security restriction make sense on the web, but XSplit is a very different environment than using it on a public website. The io class has methods for reading files from the disk and from a URL, but what is really needed is a method to write files to the hard drive (even if it is restricted to a special "XSplit files" folder). It would also be helpful to be able to get the attributes of a file (modification date, size, etc) without getting the contents so that a file could be easily monitored for changes and to get a list of the files (and folders) in a directory.

Being able to write files to the computer and monitor files for changes would enable 2 way data transfer between a plugin/extension and command line tools, custom GUI apps and other programs on the computer.

Allow grouping of sources

Someone should really consider creating groupings, with a collapsible tree view so items could be put into logical groupings and save some space. Disabling a group of items rapidly from a grouped tree view would be pretty slick too. While you can accomplish this by creating different scenes the GUI gets fairly messy when you start inputing several items.
~ tkntobfrk

This was originally filed on #6

Allow getting and setting of any generic item property

For the upcoming hackathon, we will surely get many support requests about handling this and that property. We might want to refactor our code to allow manipulation of item properties without needing to create new wrapper handler functions for every single one of them, as long as the native property name is provided.

Interface documentation for Item subclasses should be centralized in the interface

We are using TypeScript interfaces and mixins to implement common sets of methods such as Layout and Transition related methods. In the current state of the framework, documentation is repeated across all the implementing Item subclasses, sometimes leading to missing or inconsistent documentation, and frequently causing lots of code repetition (especially with sample code snippets.)

Because they all work in essentially the same way, it should be possible to strip all documentation (of these interface methods) from these separate subclasses and move all of it to the interfaces instead. We should then expose the interfaces to our generated API documentation, and all Item subclasses should now link to these interfaces instead.

The end result will be a much clearer and more organized API reference.

Possible bugs when manipulating configuration object on save-config event

The source properties window cannot save a configuration object by itself. Because of this, we designed the framework to abstract this behavior through (ItemConfigurable) requestSaveConfig method and the save-config event.

However, we're also using the configuration object internally to store the URL of the correct source properties HTML for each source. loadConfig has no problems since we hide such 'global' configurations from the developer, but we do not hide handle this in the save-config event, which can lead to cases such as a developer looping through all nodes in the configuration object and getting undefined because they assume that there are no other nodes in the object.

HTML tab in useTabbedWindow

I am trying to add a plugin config tab using the useTabbedWindow function. The new tab works fine (and is a better solution than the old 'Configure" button), but while I can use tabOrder to add the standard Layout, Color and Transition tabs, I don't seem to be able to get the standard HTML Tab. This means that if I want a custom config tab, I don't have the Playback, Display or Custom Code sections, even if they are specified in the xml file. Playback and Custom Code aren't that big a deal, but the Display section is the only way to set the resolution of the HTML document, show/hide the scrollbars and show/hide background transparency. There also does not appear to be any way to manually set any of these settings in the API.

Interestingly, if I disable the custom config tab by commenting out the <meta name="xsplit:config-url" tag in the source plugin html file, I can use the default HTML tab to set the resolution and disable scrollbars, then uncomment meta tag and refresh the source. While I lose the HTML tab, the custom resolution stays even if I save and reload the presentation. Obviously this is not a good solution, but it shows that the settings work fine, there just isn't a good way to access them.

Missing old API functions/events

This new API seems much cleaner than the old JS API and using promises instead of the OnAsyncCallback system makes a lot of sense. I was really hoping that the new API would enable new functionality, though, but you seem to have actually removed some of the events and functions I was using. Specifically, there doesn't seem to be an OnSceneLoad event anymore and I don't see anything that would be the equivalent of the recstat property in the old API.

Using recstat to get the data about length, name, target file, etc of the currently active stream(s) is particularly important for several of the plugins I have built using the old system. I have one that tracks and saves scene changes to a file so that the video can be post-processed and one that displays a timer for the length of the current stream (so the people on camera know when to wrap up).

Is there a way that I am missing to get this information with the new API? If not, is this something that is going to be added to the API soon?

Standardize naming of classes to be consistent with our public nomenclature

We've undergone several iterations of the framework now in order to get to the point where we are able to very clearly and accurately represent the different elements of XSplit Broadcaster. However, we still retain the same naming from our very first attempts at creating the framework. These naming conventions may cause confusion if they do not match the terminology we use to communicate with users publicly.

For example, we use Item / GameItem / HTMLItem etc., for our different types of sources. The term item is not very clear in this regard. Also, we use the term Source Configuration Window to refer to what we publicly call source properties dialog (I also see us occasionally using source properties window for this.)

In line with our other efforts for consistency and standardization (#28, #17), I propose we change all Item / GameItem etc. references to Source / GameSource instead. I also propose we change the name SourceConfigurationWindow into SourcePropertiesWindow (SourcePropertiesDialog might also work, but I personally think that the words "source properties" are already clear enough, and we're already using "window" for the other corresponding classes: SourcePluginWindow, ExtensionWindow).

Do you think this is a good move, @SML-MeSo, @dcefram ?

Allow plugin to request changing of source properties dialog title

The title of the source properties dialog shows the name of the source selected (plugin name, or the custom name for the source if set by user). Any changes to the plugin name while source properties dialog is open is only reflected in the sources list, and not on the source properties dialog. Thus, a new method trigger that change without needing source properties dialog to close.

  • Note that re-opening the source properties dialog will display the name of the source (as displayed in the sources list) regardless of what you set via this call.

Add support for game auto-detection

(moved from internal issue tracking: PLG-173)

Currently, the framework only allows you to add currently running games. Mimicking the auto-detect feature in the main application will be helpful.

Create Media Item class

We'll need to consider if there are differences across different types of media that will prompt us to handle it differently.

Playback methods for media sources

xjs v0.8.0 currently only supports the layout, color, chroma and transition interfaces. We need to allow usage of the 'playback' interface (basically all methods found in Media Tab).

loadConfig() within scene-load handler

I am working on an extension that allows modifying several of the Items in a scene at once. When I first load the extension, I can get a list of the items in the current scene, iterate through them and loadConfig() on each to get their current settings. When the user switches to a different scene, the extension needs to load the items from the new scene and that is where I am having trouble. Within a scene-load handler, I can load all the items in the new scene, but if I try to loadConfig() on any of them I just get an empty object. Using looking at the items shows that they are loaded successfully and the config data is in the xml definition. Theoretically, I guess I could manually parse it from the raw xml, but that seems wasteful when loadConfig() is supposed to do what I want.

Sample code:

extensionWindow.on('scene-load', function(){
    xjs.ready().then(Scene.getActiveScene)
    .then(function(currentScene){
        return currentScene.getItems();
        }).then(function(items){
            console.log(items[0]) //logs a normal Item object
            return items[0].loadConfig();
            }).then(function(config){
                console.log(config); //logs an empty object
            });
});

Cheers,
Paul

Add support for DLL usage

Our keyboard sample plugin makes use of native DLL calls to accomplish its task.

For the first phase of our framework's DLL support, we might consider exposing methods to invoke any and all DLL calls.

We can expand the framework's support of the feature later on once we figure out how to handle this correctly.

xjsframework/xjsframework.github.io#5 should be done together with this item.

Create Screen Region class

(moved from internal issue tracking: PLG-199)

Currently in PLG-199 branch, and assigned to me for review

Create composable search functions

For our own sanity ๐Ÿ˜‰ , we will rework our item and scene search functionality into composable and extensible functions. This will solve the need for the multitude of possible use cases.

This will solve issues similar to #9 and #10.

Support for source list events

We need to wrap the update/highlight/select events of the source list (see internal item CPPCORE-876)

These events are only receivable by extensions.

Inconsistent naming of functions

In order to avoid any confusion, we should establish naming standards with our functions before we declare a stable version (1.X.X or higher) and start to avoid making breaking changes. Specifically, we should change all "getID" calls into "getId" as there is precedent in the native JavaScript function document.getElementById.

Any other inconsistencies should also be addressed in this issue.

save active extensions with presentation

When an extension is integral to a particular presentation, it would be nice if it were possible to save the current active extensions (along with their window size/position) as part of a presentation so that they open automatically when the presentation opens. In the current system, if there is an extension that is used all the time, you still have to reopen it each time you open xsplit.

As a related feature, it would be useful to be able to activate and possibly manipulate an extension from another plugin or extension.

Most efficient way of show/hide item

I played around with .setVisible(false), and noticed some newer methods like searchAllForItemId & getCustomName. What do you think the best way to show/hide an individual item would be in the new framework?

I was considering exploring searchAllForItemId.

It seems like a function could be created, takes in Custom Name as search parameter + true/false

That function could get the ID and pass it to a function with searchAllForItemId, which you could then chain the visible true/false state to?

But perhaps there's some incompleteness or speed impacts of doing it that way. Just wondering what would be the best way in the current framework.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.